xPDO XML Schema for built-in MODx tables

Would you think that the modx users would define its id column as a primary key in the XML schema? But in core/model/schema/modx.mysql.schema.xml I don’t see a field definition for an auto_increment primary key column. Is that correct?

It extends modPrinciple which extends xPDOSimpleObject.
xPDOSimpleObject defines the primary key.

Ah... so it’s not the simple example I was hoping for. Is the XML schema referenced by this post still valid?

http://modxcms.com/forums/index.php/topic,11601.0.html

2007... that had to have been xPDO version 1, but THOSE relationships look sensible to me. I’m guessing that’s because there isn’t the same amount of hierarchy of object classes in older versions of xPDO...

Thanks!

Hey, I was wondering where that post had gone, thanks!
I’m pretty sure that’s Jason’s xPDO model for the Evo database.
Look in core/model/schema for modx.mysql.schema.xml for Revo.
2007.. wow.

I know where the current Revo schema is, but it’s not a good example for someone trying to learn how to associate tables. The Revo XML schema uses a lot of inheritance and parent/child references that go far beyond the simple relationships you would need to define when relating 2 or 3 database tables together. See my other post:

http://modxcms.com/forums/index.php/topic,53863.msg311354.html#msg311354

I’m talking out of my butt here, because I’ve never actually done what you’re trying to do, but take a look at modResource, modResourceGroup, and modResourceGroupResource for a fairly simple 3 table many-to-many association. Delete the word "accessible" and most (all?) of the aggregate aliases and all the composite aliases that don’t refer to one of the three objects and it should be close to what you need.

Doing the same with modChunk and modCategory would be close to what you need for a one-to-many 2 table relationship.

Hehehe... yeah, the name of the game is presenting this in a logical fashion so someone who understands how to set up a relational database would know how to do this in the XML schema (e.g. imagine a bunch of MySQL InnoDB tables).

I know how to architect a database... but understanding "composite" and "aggregate" with different cardinalities is proving difficult just because I’m not sure how to look at it. There’s a lot of room for misunderstanding when your left is my right -- that sort of thing. It’s similar to how you have to set up the "ON DELETE" or "ON UPDATE" clauses in your InnoDB definitions... cascading options etc.

So far, I’ve gotten xPDO working enough to join 2 tables, but not 3: http://modxcms.com/forums/index.php/topic,53869.msg311373.html#msg311373

Once I figure this out, I’ll finish my write-up... I hope that would prove really useful to others who want to see how a set of MySQL tables translates into XML and how a given set of queries translate into xPDO’s Active Record implementation.

More examples of XML and table definitions are welcome!

I know what you mean and I’m sure that your work will be really valuable to others.

For cardinality, I think it helps to ask whether the class you’re defining could be attached to more than one of the thing named in the alias. A user can only have one Profile, so in the modUser class, the cardinality of the Profile alias is one. Similarly, a given Profile can have only one user, so the cardinality of the modUser alias in the modUserProfile class is also one.

For one-to-many relationships, the category can have many chunks so the Chunk alias in the modCategory class has a cardinality of "many." The chunk, though, can belong to only one category, so the Category alias in the modChunk class has a cardinality of "one."

For many-to-many relationships, the user group can have many users and the user can belong to many groups. So the cardinality for the User alias in the modUserGroup class is "many." The same for the UserGroup alias in the modUser class. But the intersect object, modUserGroupMember, is one row in the intersect table, so it can have only one user, one role, and one user group -- so a cardinality of "one" for each of those aliases (User, Role, and UserGroup) in the modUserGroupMember class.

I finally finished my documentation page:
http://rtfm.modx.com/display/xPDO20/More+Examples+of+xPDO+XML+Schema+Files

I believe the answer to this is to define the relation (an aggregate) in your 3rd party custom table. When you need to load up all the user data, load up the object for your custom table, then connect to the related MODx table. The MODx table doesn’t need to know that it’s being connected to.