Targeting custom xpdo domain model with different table prefix

I have some 30 odd tables with a table prefix other than modx. Understandably this was done for readability and usability purposes. I understand that an instance of modX is instantiated using the default modx prefix and any method calls on my package always resolve the a table prefixed with modx_. In the db xml schema the object element has a table name attribute, is there any other attribute that can be specified to read the name literally? Or better yet specify the table prefix in the model elements attributes?

I guess one way could be via the xml schema but any other solution to this issue will suffice...

Extend xPDO instead. Here’s an example piece of a map file where I’m using a table named "resume_form".

Yeah, if you want to maintain two separate table prefixes for MODx and your custom tables, you’ll need to maintain two different xPDO instances. Otherwise, I would recommend using table_prefix in the same way for your custom tables, so that it would have the same modx_ prefix. Or simply don’t use a prefix.

Otherwise, I would recommend using table_prefix in the same way for your custom tables, so that it would have the same modx_ prefix

With lots of custom tables I think it just becomes too scattered between all of the modx tables and during development or maintenance its just becomes a nuisance trying to locate the right table.

Extending the modX object is an viable option but that means changing the core files which actually instantiate the object, now, and on every upgrade. Also, maintaining a second instance of modX I would only consider if I’m targeting a different database, otherwise its too much overhead, and because my lack of understanding of the framework as of now I don’t know what caveats or problems that might cause in the long run with the manager and the front end.

So far I have gotten around it with prefixing my tables like this: modx_myprefix_tablename. This solves the readability issue, but doesn’t look as nice (you guys are picky about naming too). But I still think there should be an extra config option for specifying the table prefix in the domain object map. This would make any third party table very easy to locate without regard of the number of tables inside the db.

Thanks for the help.

Quote from: airoctive at Jan 06, 2009, 10:20 AM

Extending the modX object is an viable option but that means changing the core files which actually instantiate the object, now, and on every upgrade. Also, maintaining a second instance of modX I would only consider if I’m targeting a different database, otherwise its too much overhead, and because my lack of understanding of the framework as of now I don’t know what caveats or problems that might cause in the long run with the manager and the front end.

No, you would simply extend xPDO to create a custom model, not the modX class. The modX class is the custom model class for the modx content management system. All you want is an isolated connection to your model, but you happen to keep that model in the same database. To use the same connection, you would just use the modX class itself (no extension necessary). To use a separate connection, you just extend xPDO or create a new instance of it in your code.

Quote from: airoctive at Jan 06, 2009, 10:20 AM

So far I have gotten around it with prefixing my tables like this: modx_myprefix_tablename. This solves the readability issue, but doesn’t look as nice (you guys are picky about naming too). But I still think there should be an extra config option for specifying the table prefix in the domain object map. This would make any third party table very easy to locate without regard of the number of tables inside the db.

Again, table prefixes are run-time only, not design-time. This is on purpose to allow running multiple instances of a model in the same database, just like MODx has always allowed. I think you are simply over-thinking this; if you have no table prefix, that should be the actual names of your tables, then adding various prefixes would allow you to have multiple instances of each table in the same database container when working with a specific connection.

An option I might consider in future releases of xPDO is being able to apply specific table-prefixes by package, then you can use a single connection to work with multiple models that have distinct table prefixes configured.