Using foreign Database

I know I’ve asked this before... but how do your XML schema definitions change if you use a foreign database to hold your tables? I know how to connect using xPDO separately, but if I’m writing Snippets/Plugins, is there anyway to make the $modx object access that other database?

Thanks!

Maybe by using getService: http://rtfm.modx.com/display/revolution20/modX.getService

Thanks. I’m not sure exactly how that would work though since my understanding of a "service" is pretty limited. Man, I *know* I figured this out at one point, but I can’t find it for the life of me.

Ok, I found my example of this... the solution is not ideal, but it works. Basically, I instantiate a new instance of xPDO. Here’s what my snippet looks like:



Then all the methods that I normally would run on the $modx object, I end up running on the $my_xpdo object.

What would be ideal, in your perspective, when connecting to external databases with xPDO (or MODx)?

I filed a feature request for xPDO:
http://bugs.modx.com/issues/2851

Logically, I tend to think in terms of establishing a connection, then retrieving an object from that connection. Perhaps one implementation would be to add an additional argument to the getCollection or getObject methods... but cleaner would probably be adding attributes to the XML schema definition that specified the source database for any given table (i.e. object). It could rely on aliases, too, so that if you have a custom site_content table (for example), you could give it a separate alias so as not to conflict with your MODx site_content table.

Perhaps it boils down to whether you think of xPDO as an abstraction of a single database, or more as a database handle that abstracts all databases/tables that it has access to.

Quote from: Everett at Nov 23, 2010, 10:56 AM

I filed a feature request for xPDO:
http://bugs.modx.com/issues/2851

Logically, I tend to think in terms of establishing a connection, then retrieving an object from that connection. Perhaps one implementation would be to add an additional argument to the getCollection or getObject methods... but cleaner would probably be adding attributes to the XML schema definition that specified the source database for any given table (i.e. object). It could rely on aliases, too, so that if you have a custom site_content table (for example), you could give it a separate alias so as not to conflict with your MODx site_content table.

Perhaps it boils down to whether you think of xPDO as an abstraction of a single database, or more as a database handle that abstracts all databases/tables that it has access to.

Thanks for entering that Everett.

The schema is all design time information; database connection, table_prefixes, and other configuration is only runtime. This should never be handled in the schema IMO; that is akin to hardcoding absolute paths into your content. I was thinking more along the lines of a single xPDO instance handling multiple PDO objects (which have to represent a single connection), and allowing you to map those PDO connections to specific packages in the same way that table prefixes are currently. This matches the design-time/run-time separation and provides a way to not only handle model specific connections, but could also be the foundation for providing multiple connections for master/slave database configurations where you want writes to go to one master connection, and reads to be pooled across the available slave connections.

I was thinking more along the lines of a single xPDO instance handling multiple PDO objects (which have to represent a single connection), and allowing you to map those PDO connections to specific packages in the same way that table prefixes are currently.

That sounds like an intriguing possibility. If there’s a way to implement it in a way that follows the architectural principles, then I’m all for it.