I wasn't aware that I'd broken anything. The 1.22 version still has all the multi-inheritance code in it and should still work. I have a major application using the latest version of the framework and everything is OK with that. Also, my testing that I did against it seemed OK last time I checked, but I might have missed something.
If I screwed it up I apologise and I'll fix it ASAP, just post a test case that shows what I broke.
- Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-08-31
Hi Richard,
I've posted a bug report and attached a project.
Dan.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If C and D are both persisted objects, and share the same Class B key values I can't figure out which object to instantiate.
For example, B is a Person (J.Citizen) and C is an Employee (subclass of Person) and D is a Manager (subclass of Person). If J.Citizen is an employee and also a manager, when I load class A, do I load an Person, Manager or Employee object?
At the moment, we would load an Employee (first valid instance) but it may not be correct.
Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-09-09
Hi Richard,
If both classes C and D are persisted in the database then both objects should be instantiated.
I think that the important thing remember is to retrieve the object to the exact state prior to persisting it.
In OO world, it is allowed for both instances of type C and D to co-exist, although both share some of the attributes. Perticulary, the parents attributes. But, they are still two separate objects.
So, if we reflect that behavior of OO to a persistent module. Then, it means that there should be two separate rows inserted into the table that correspond to class B, the father class. And, two separate rows inserted into tables coresponding to class C and D respectivly. The binding keys are the reference keys fields and also the OIDValue field. This is, to me, very important. This way we are able to instantiate the objects to their exact state prior to persisting them.
So, during retrieve it needs to verify which class to instantiate by checking, not only the parent table but also the child table.
And, if you have a situation like in your example, a Person which is an Employee and also a Manager, and there are instances of Employee and Manager in the database. Then, I think that there should be two objects instantiated. One, an Employee and a second, a Manager.
If you think about it, an Employee and a Manager depends only in the context that it is used. So, they both can "live" in the database and in the OO world at the same time.
I hope this helps.
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply. It's the same as what I am thinking.
I don't know if I quite explained the difficulties of the problem properly.
Lets say class A has a strongly typed collection of Class B objects.
We can save object A, all the objects in the B collection are saved correctly (even if collection contains subclassed objects of class B). On retrieval we can even get all the objects in collection back in the same type that they were saved as long as there is only one subclassed instance in the database.
What happens when I have multiple objects inheriting from a single classB object? When I try to retrieve the collection I will return the first subclassed object I find, even if that is not the object that was saved with the collection (ie returning a class C object in the collection instead of the class D one)
The problem I have is that I can't persist the type of objects in the database to be able to guarantee the correct retrieval of the data. If it's a new database, maybe we can do something, but against legacy data, it's not so easy since db schemas can't always be changed.
So what I was trying to nut out was the strategy I could use to persist the type of an object participating in an association at the time it was saved (ie the state of the collection)
There's also another problem. Lets say I create a class B object and create subclassed C and D objects from that B object. I can do a retrieve of a single object, but If I retrieve an object of class B, do I return the B, the C or the D object? I would think the B object, but I just want to get your ideas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-09-09
Hi Richard,
I agree. B object should be instantiated.
Legacy data is a problem.
But, I think that if all records in the tables include some kind of a unique id, like OID or GUID, you can find out exactly which object to instantiate just by elimination process.
Dan.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Richard,
I've downloaded the latest version from the CVS.
And, I found out that the multiple inheritance does not work at all.
It seems that the code returned to the previous functionality before the changes I made.
Is there a reason for that?
Dan.
Hi Dan,
I wasn't aware that I'd broken anything. The 1.22 version still has all the multi-inheritance code in it and should still work. I have a major application using the latest version of the framework and everything is OK with that. Also, my testing that I did against it seemed OK last time I checked, but I might have missed something.
If I screwed it up I apologise and I'll fix it ASAP, just post a test case that shows what I broke.
- Richard.
Hi Richard,
I've posted a bug report and attached a project.
Dan.
Hi Dan,
Thanks. I'll check it out today.
Hi Dan,
When I have a situation such as:
A -> B (1..N)
C inherits from B
D inherits from B
If C and D are both persisted objects, and share the same Class B key values I can't figure out which object to instantiate.
For example, B is a Person (J.Citizen) and C is an Employee (subclass of Person) and D is a Manager (subclass of Person). If J.Citizen is an employee and also a manager, when I load class A, do I load an Person, Manager or Employee object?
At the moment, we would load an Employee (first valid instance) but it may not be correct.
Any thoughts?
Hi Richard,
If both classes C and D are persisted in the database then both objects should be instantiated.
I think that the important thing remember is to retrieve the object to the exact state prior to persisting it.
In OO world, it is allowed for both instances of type C and D to co-exist, although both share some of the attributes. Perticulary, the parents attributes. But, they are still two separate objects.
So, if we reflect that behavior of OO to a persistent module. Then, it means that there should be two separate rows inserted into the table that correspond to class B, the father class. And, two separate rows inserted into tables coresponding to class C and D respectivly. The binding keys are the reference keys fields and also the OIDValue field. This is, to me, very important. This way we are able to instantiate the objects to their exact state prior to persisting them.
So, during retrieve it needs to verify which class to instantiate by checking, not only the parent table but also the child table.
And, if you have a situation like in your example, a Person which is an Employee and also a Manager, and there are instances of Employee and Manager in the database. Then, I think that there should be two objects instantiated. One, an Employee and a second, a Manager.
If you think about it, an Employee and a Manager depends only in the context that it is used. So, they both can "live" in the database and in the OO world at the same time.
I hope this helps.
Dan
Hi Dan,
Thanks for the reply. It's the same as what I am thinking.
I don't know if I quite explained the difficulties of the problem properly.
Lets say class A has a strongly typed collection of Class B objects.
We can save object A, all the objects in the B collection are saved correctly (even if collection contains subclassed objects of class B). On retrieval we can even get all the objects in collection back in the same type that they were saved as long as there is only one subclassed instance in the database.
What happens when I have multiple objects inheriting from a single classB object? When I try to retrieve the collection I will return the first subclassed object I find, even if that is not the object that was saved with the collection (ie returning a class C object in the collection instead of the class D one)
The problem I have is that I can't persist the type of objects in the database to be able to guarantee the correct retrieval of the data. If it's a new database, maybe we can do something, but against legacy data, it's not so easy since db schemas can't always be changed.
So what I was trying to nut out was the strategy I could use to persist the type of an object participating in an association at the time it was saved (ie the state of the collection)
There's also another problem. Lets say I create a class B object and create subclassed C and D objects from that B object. I can do a retrieve of a single object, but If I retrieve an object of class B, do I return the B, the C or the D object? I would think the B object, but I just want to get your ideas.
Hi Richard,
I agree. B object should be instantiated.
Legacy data is a problem.
But, I think that if all records in the tables include some kind of a unique id, like OID or GUID, you can find out exactly which object to instantiate just by elimination process.
Dan.
I think I'll release a new version soon, and then do some more thinking about this problem after that...
Thanks for the input :-)