Skip to Content (c) Skip to Navigation (n) Skip to Search (s)

Download 2.1.2-pl

xPDO 2.1.2 Public Launch

xPDO 2.1.2-pl is now available. Download it!

Download 2.0.1-pl

xPDO 2.0.1 Public Launch Now Available

xPDO 2.0.1-pl is now available. Download it now and help test the sqlite and sqlsrv drivers.

Forgotten credits...

I'd like to extend a special thanks to Andrea Giammarchi for his PDO for PHP 4 implementation that inspired me to begin coding this project. If not for PHPClasses.org and the inspiration I found in Andrea's work there, the OpenExpedio project would likely not exist, as I probably would have invested my time in working with PHPDoctrine.

Migration Guide: xPDO 1.0 beta

Changes to xPDO model class/map structure

In preparation for implementing SQLite and PostgreSQL support for 1.0 final release, 1.0 beta introduces a slightly different class/map structure. Previously, all of the generated classes and maps that make up your model were generated in the mysql subdirectory of your packages root directory. As of 1.0 beta, xPDO requires a database independent class file in the root of your package, in addition to the mysql specific class. This means that your existing class files need to move up one directory, to the package root (maps stay the same), and a new class stub needs to be generated in the mysql subdirectory. The new class will have the same filename but the actual class name will be Classname_mysql (the _mysql is added automatically). This change was made in order to support loading of multiple database-specific implementations of the same class in a single request.

Changes to xPDO aggregate and composite definitions

Another important change in the beta release of xPDO is the way that aggregate and composite definitions are defined. Prior to beta releases, in order to identify multiple unique relationships to the same foreign class, you were required to define a key attribute. Consider a self-referential relationship:

<object class=”ClassA”>
    <aggregate class=”ClassA” key=”parent” local=”parent” foreign=”id” cardinality=”one” />
    <composite class=”ClassA” key=”id” local=”id” foreign=”parent” cardinality=”many” />
</object>

This required that you specify the key when calling API functions or accessing related objects.

To relieve this cumbersome requirement, xPDO 1.0 beta now provides a way to refer to distinct related objects by an alias, simplifying the API calls and allowing the way related objects are both accessed and processed. Here is the above definition in xPDO 1.0 beta:

<object class=”ClassA”>
    <aggregate class=”ClassA” alias=”parent” local=”parent” foreign=”id” cardinality=”one” owner=”foreign” />
    <composite class=”ClassA” alias=”children” local=”id” foreign=”parent” cardinality=”many” owner=”local” />
</object>

Notice, I've also introduced the owner attribute, which helped solve some bugs when dealing with certain kinds of compound primary keys, and also allowed for better optimization of related object processing. This simply defines if the local or foreign attribute is the owner of the key in the relationship.

Changes to xPDOObject related object structure and methods

The simplified structure for modeling related objects in 1.0 beta also allows more direct access to those objects via the API. Many of the methods of xPDOObject and xPDOQuery that previously required a class and key parameter now take only a single parameter which can be the alias (or it can still be the class name if only one relation to that class exists). Here is a list of the methods you will need to look for usage of in your xPDO code and update:

  • xPDO

    • getObjectGraph() – Graph parameter format has changed, use array ('relationAlias' => array ()) or {“relationAlias”:{}} since relation keys are no longer applicable. Subrelations will now be direct: array ('relationAlias' => array ('subRelationAlias' => array ())) or {“relationAlias”:{“subRelationAlias”:{}}}. Please note that the empty array is still necessary to process each relation.

    • getCollectionGraph() – same as for getObjectGraph

    • getFKDefinition() – no more key parameter; access foreign key definitions using parentClass and the relation alias

  • xPDOObject

    • getOne() – no more class and key parameter; replaced with alias parameter

    • getMany() – no more class and key parameter; replaced with alias parameter

    • addOne() – k parameter replaced with alias parameter

    • addMany() – k parameter replaced with alias parameter

    • getFKDefinition() – class and key parameters replaced with alias parameter

  • xPDOQuery

    • join() – removed key parameter

    • innerJoin() – removed key parameter

    • leftJoin() – removed key parameter

    • rightJoin() – removed key parameter

    • from() – removed key parameter

    • bindGraph() – see changes to the way graphs are now specified in xPDO :: getObjectGraph description above

Summary: steps to upgrade your classes and regenerate your maps

  • First, back up your existing model classes and maps.

  • You'll want to edit your aggregate and composite elements in your schema, replacing key with an alias that will represent that class relationship uniquely, and define an owner for it, with local or foreign as the value.

  • Move all of your existing *.class.php files from your model mysql directory up one level, to the root of your package. DO NOT move the map files; leave them in the mysql subdirectory of the package root.

  • Now, regenerate your model classes and maps; your classes with domain logic will be skipped and the new _mysql stub classes will be generated in the mysql subdirectory.

  • If you've added code with MySQL-dependent SQL statements into your classes, you'll likely want to move those into the newly generated _mysql stub class in the mysql subdirectory.