extends="xPDOObject" vs extends="xPDOSimpleObject"

After generating some XML schemas I notices that some objects extend xPDOObject while others extend xPDOSimpleObject. I’m just curious here, but why the difference? Nothing in those tables would seem to indicate a preference for one or the other. Was it something I said?

But my mistake, one of the two possibility don’t have an auto-increment id field

Hello Everett

Some objects extend xPDOObject while others extend xPDOSimpleObject.

Using xPDOSimpleObject allows you to not specifiy a id column in your table as primary key. xPDOSimpleObject "auto-generate" the id column as primary key (with a name of "id") so you don’t mention the ID field (column) in your schema



Even if not written in the schema this object has a field called "id" that is a primary key, this is possible because it extends xPDOSimpleObject

If you want the same object extending xPDOObject you have to specify which column is used as Primary key (it can be an additional field named "id" or an existing field)

Hope this can help you, and sorry for my english ...

yeah, not autoincrement but primary, that’s what i wanted to say... :/

ah, that does explain it. Makes sense. The "simpleObjects" are the ones where the primary key is named "id" whereas the regular objects have ids with a fully qualified table name included, e.g. mytable_id.

Quote from: Everett at Dec 02, 2010, 10:46 AM

ah, that does explain it. Makes sense. The "simpleObjects" are the ones where the primary key is named "id" whereas the regular objects have ids with a fully qualified table name included, e.g. mytable_id.

Actually, the base xPDOObject map does not define any fields, leaving it up to you to define the primary key as you desire. xPDOSimpleObject simply adds the id field in it’s map, which is inherited by any classes in your model that extend it instead of xPDOObject directly. It’s both a simple way to get started with a primary key field and an example of how the xPDOObject classes inherit their fields and other map attributes all the way through their ancestry.

Thanks for the clarification. Man, I feel like I’ve just scratched the surface here. It’d be a cool "how-to" if we could come up with some simple use cases of how to define those class inheritances in the XML schema.... but that’s for another day (and for another thread).