Extending Query

I’m working on software which makes use of various design patterns and consequently also a lot of polymorphism by extending various class in different way to create factory, builder and composite etc patterns.

Now the problem I’m facing, or which I might be implementing incorrectly is that I’m not sure the extending of class/objects within the database/model is working the way I thought it was suppose to work, but please correct me if I’m wrong. I’ll try and add xml code to try and help explain what I’m depicting...

Now let’s say we have class Product which extends from xPDOSimpleObject with it’s associated attributes and relationships within that class/object. Now we may have a SpecializedProductA and SpecializedProductB which extends Product. In effect both of these are xPDOSimpleObject classes/objects but each with the own set of additional and different attributes. This should be fairly straight forward to understand.



Now upon executing the save method to save the specialized products I would thinks that the product attributes within this hierarchy will be saved within the modx_test_Product class, and the additional attributes of the specialized classes respectively in modx_test_SpecializedProductA and modx_test_SpecializedProductB. What appears to be happening is that SpecializedProductA creates a table with all the attributes from Product as well as it’s own additional attributes which I don’t want, as I want the information (or data) which is relevant to the specific object to be saves in their respective tables, not everything in one table.

I found the problem when I wanted to exploit the usage of using the modResource class/object as a base/parent class which Product would extend, so that when I save a Product object, that the modResource attributes are still saves in modx_site_content and the Product attributes in modx_test_Product, but what happens is all the attributes found in modResource is nou saved in modx_test_Product which means the Product which is actually a type of modResource is never shown on the resource tree as it is never saved in the correct place.



How would one approach such a scenario for this to work correctly? I’ve recently noticed a class_key attribute in some tables, does this have something to do with it? Because let’s say I need a specialized user class/object would I extend modUser but in the modx_users table change the class_key to ’SpecializedUser’? And where does it save the additional attributes then?



Sorry for all the reading and question, but I’m trying to learn more about how to use modx and xpdo as it is one of the most awesome cms’s (or cmf’s) I’ve ever come across and for future project where we used to use Joomla for only start using modx now because it is so awesome!

This is just off the top of my head, and a better answer is bound to come along from someone else, but here’s an idea.
In the xPDO Schema file, have your SpecializedProductA object extend xPDOSimpleObject. Set up the relationships you want between Product and your SpecializedProducts. This will make sure that your SpecializedProductA tables only contain the fields that you want.
When your stub classes are generated, you can change the inheritance in the PHP code. Then if you want a SpecializedProductA object to return fields that are actually stored in a related Product object as if they are it’s own, you’ll have to override the accessor methods. I’m probably bringing some new problems to the surface, but that’s my 2-bit suggestion

Quote from: netProphET at Jul 15, 2010, 06:04 PM

This is just off the top of my head, and a better answer is bound to come along from someone else, but here’s an idea.
In the xPDO Schema file, have your SpecializedProductA object extend xPDOSimpleObject. Set up the relationships you want between Product and your SpecializedProducts. This will make sure that your SpecializedProductA tables only contain the fields that you want.
When your stub classes are generated, you can change the inheritance in the PHP code. Then if you want a SpecializedProductA object to return fields that are actually stored in a related Product object as if they are it’s own, you’ll have to override the accessor methods. I’m probably bringing some new problems to the surface, but that’s my 2-bit suggestion

I have been actually thinking along the same line as the work around, I think I would then have to make them composite relationships so that when you delete the SpecializedProductA it will remove the Product as well and consequently if Product has the same with regards to a modResource object, it should then in theory remove the modResource object/instance from the database as well?

xPDO does not currently support multi-table inheritance models like this. Single-table inheritance is supported using a class_key field (and is how modResource works). There is a sort of multi-table inheritance going on with modElement (some derivatives have their own tables, some don’t have tables), but this is not handled in the xPDO layer; only in the implementation of the classes.

Ok, will then try doing the composite relationship route to enable effective cleanup of instances in the various tables while limiting it to single inheritance...