I'm using the AtomsFramework is a persist a large object graph. We are using many structs, classes, inheritance, enums and complex Ids.
I read the tutorial and looked for examples describing how to persist descendent classes and I couldn't find any.
Also, Can I persist a struct? and an enum?
We also have complex Ids for several classes which we hold them in structs. Is there any way to sign a class property of some struct type as "key"?
Thanks in advance,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Persisting structs and enums
------------
Sorry Dan, it can't be done. You must inherit from the CPersistentObject if you want to persist anything through the framework, which restricts you to using classes.
In any case, persisting a enum doesn't make sense since it is actually defined in the source code and cannot be changed at run time (unless you are emitting code via reflection).
If you convert your structs to classes you would be able to persist them, although I don't know what impact this would have on your code and how much refactoring would be involved.
Persisting Inheritance
--------------------
Yes! You need to use SuperClasses. There are two ways that you can arrange this in your database. The first is to use separate tables for each concrete class and the second is to share a table between a parent class and it's children.
The 1 table per concrete class is the preferred method and is fairly well proven. The shared table method is only new and has been through some initial testing but I expect that there are still some issues with it.
For 1 table per class you need to do two things. Firstly in your child classes you must add a reference back to the parent class in the XML mapping using SuperClass="parentclassname". Secondly you need to have a reference from a child class attribute back to the parent class attributes (key fields).
For instance you may have a class structure where "CStudent" and "CTeacher" both inherit from "CIndividual".
In your XML mapping (or your attributes) you would indicate that the CStudent class has CIndividual as its parent class using SuperClass="CIndividual".
Assume also that the CIndividual class uses a Year and IDNumber as the key (not an OID or a GUID). The CIndividual table would have two key columns (year and idnumber) and then data columns. The Student table would also have two key columns (year and idnumber) and then specific data columns related only to the student class.
In the XML we define the linkage from the child class back to the parent by using the reference tag on the attribute. Something like
<attribute name="year" column="year" reference="year" key="primary"/>
<attribute name="IDNo" column="year" reference="IDNumber" key="primary"/>
Overall, the database would have three tables - Individual, Student and Teacher. When a student is retrieved a join is performed between the Student table and the Individual table based on the reference attributes.
If performance is an issue and you wish to avoid the join then you can use a shared table.
This concept would involve storing all the information about individuals, students and teachers in the one table. Typically when this happens there is a column in the database table that indicates the type of record stored, for example "IType" might be blank for an unassigned individual, "S" for Students and "T" for teachers.
To use a shared table you still need to set the SuperClass tag on the mapping, however you also need to indicate the SharedTableField and the SharedTableValue. When these values are set it is assumed that information from the superclass is held in the same table as this class.
For our example teh CStudent class should have the SharedTableField = "IType" and the SharedTableValue should be "S".
Using Structs as Keys
---------------------
I understand the issue here (from our example you would have a struct with Year and IDnumber and use this as a single property in the class definition).
This isn't catered for and probably won't be in the near future (though I have put it on the feature requests). The difficulty is in the mapping. The year and idnumber could map to "Yr" and "IDNo" in one table (the CStudent for example) but in the CTeacher table it may be mapped to "Year" and "IDNumber".
I hope that all of this clears things up for you :-)
If you have more questions please ask
-Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-06-07
Hi Richard,
I'm a little confused about the inharitance.
I understood from the tutorial, that only the oid column must be a primary key. Did I understood correctly? Or, can I set other columns to be primary keys instead of the oid column?
What do you mean by "Secondly you need to have a reference from a child class attribute back to the parent class attributes (key fields)"? Do you mean, only in the XML mapping file or both in code and XML mapping file?
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The OID Column should be the primary key (if you use OIDs) but you can also have a second unique index on the table (the equivalent of the normal relational primary key). By marking attributes in these columns as find=true you can retrieve an object in two ways - one via it's OID using retrieve and one via the second unique key using the find() method.
The reference from the child back to the parent is the superclass attribute in the <class/> tag and the reference attributes in the <attribute/> tag. It's only required in the mapping.
I hope that clears a few things up. If not let me know and I'll post an example.
- Richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-06-08
Hi Richard,
Thanks, It helped.
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I'm using the AtomsFramework is a persist a large object graph. We are using many structs, classes, inheritance, enums and complex Ids.
I read the tutorial and looked for examples describing how to persist descendent classes and I couldn't find any.
Also, Can I persist a struct? and an enum?
We also have complex Ids for several classes which we hold them in structs. Is there any way to sign a class property of some struct type as "key"?
Thanks in advance,
Dan
Hi Dan,
Persisting structs and enums
------------
Sorry Dan, it can't be done. You must inherit from the CPersistentObject if you want to persist anything through the framework, which restricts you to using classes.
In any case, persisting a enum doesn't make sense since it is actually defined in the source code and cannot be changed at run time (unless you are emitting code via reflection).
If you convert your structs to classes you would be able to persist them, although I don't know what impact this would have on your code and how much refactoring would be involved.
Persisting Inheritance
--------------------
Yes! You need to use SuperClasses. There are two ways that you can arrange this in your database. The first is to use separate tables for each concrete class and the second is to share a table between a parent class and it's children.
The 1 table per concrete class is the preferred method and is fairly well proven. The shared table method is only new and has been through some initial testing but I expect that there are still some issues with it.
For 1 table per class you need to do two things. Firstly in your child classes you must add a reference back to the parent class in the XML mapping using SuperClass="parentclassname". Secondly you need to have a reference from a child class attribute back to the parent class attributes (key fields).
For instance you may have a class structure where "CStudent" and "CTeacher" both inherit from "CIndividual".
In your XML mapping (or your attributes) you would indicate that the CStudent class has CIndividual as its parent class using SuperClass="CIndividual".
Assume also that the CIndividual class uses a Year and IDNumber as the key (not an OID or a GUID). The CIndividual table would have two key columns (year and idnumber) and then data columns. The Student table would also have two key columns (year and idnumber) and then specific data columns related only to the student class.
In the XML we define the linkage from the child class back to the parent by using the reference tag on the attribute. Something like
<attribute name="year" column="year" reference="year" key="primary"/>
<attribute name="IDNo" column="year" reference="IDNumber" key="primary"/>
Overall, the database would have three tables - Individual, Student and Teacher. When a student is retrieved a join is performed between the Student table and the Individual table based on the reference attributes.
If performance is an issue and you wish to avoid the join then you can use a shared table.
This concept would involve storing all the information about individuals, students and teachers in the one table. Typically when this happens there is a column in the database table that indicates the type of record stored, for example "IType" might be blank for an unassigned individual, "S" for Students and "T" for teachers.
To use a shared table you still need to set the SuperClass tag on the mapping, however you also need to indicate the SharedTableField and the SharedTableValue. When these values are set it is assumed that information from the superclass is held in the same table as this class.
For our example teh CStudent class should have the SharedTableField = "IType" and the SharedTableValue should be "S".
Using Structs as Keys
---------------------
I understand the issue here (from our example you would have a struct with Year and IDnumber and use this as a single property in the class definition).
This isn't catered for and probably won't be in the near future (though I have put it on the feature requests). The difficulty is in the mapping. The year and idnumber could map to "Yr" and "IDNo" in one table (the CStudent for example) but in the CTeacher table it may be mapped to "Year" and "IDNumber".
I hope that all of this clears things up for you :-)
If you have more questions please ask
-Richard.
Hi Richard,
I'm a little confused about the inharitance.
I understood from the tutorial, that only the oid column must be a primary key. Did I understood correctly? Or, can I set other columns to be primary keys instead of the oid column?
What do you mean by "Secondly you need to have a reference from a child class attribute back to the parent class attributes (key fields)"? Do you mean, only in the XML mapping file or both in code and XML mapping file?
Dan
Hi Dan,
The OID Column should be the primary key (if you use OIDs) but you can also have a second unique index on the table (the equivalent of the normal relational primary key). By marking attributes in these columns as find=true you can retrieve an object in two ways - one via it's OID using retrieve and one via the second unique key using the find() method.
The reference from the child back to the parent is the superclass attribute in the <class/> tag and the reference attributes in the <attribute/> tag. It's only required in the mapping.
I hope that clears a few things up. If not let me know and I'll post an example.
- Richard
Hi Richard,
Thanks, It helped.
Dan