Is this a bug? Restrict prefix causes incorrect table names in custom tables

Here’s the nutshell:
1. I have a standard Revo install using a table prefix of modx_ for each MySQL database table.
2. I have added a handful of my own custom tables with their own custom prefix, e.g. my_
3. I run the script referenced here to reverse engineer the xPDO XML schema and PHP map/class files from the existing database. I have to make sure I specify the $table_prefix and that I set the $restrict_prefix to true, otherwise the reverse engineering script will generate map/class files for ALL the database tables, including the MODx ones (which already have an XML schema defined).

After this process, I end up with an xPDO XML schema that describes my custom database tables used for this particular package. BUT... the trouble starts when I tried to use xPDO to access the tables, and I noticed that they weren’t being accessed correctly (as per my other post:
http://modxcms.com/forums/index.php/topic,58060.msg331663.html#msg331663).

So I went through my XML and updated the definitions to include the full table name:

then I regenerated the map/class files.

And that has fixed the problem, but I’m surprised my solution worked at all: doesn’t the defined table prefix apply to ALL tables that are read via that instance of xPDO (i.e. via the $modx object)?

So given a simple xPDO method:

am I correct in guessing that xPDO first looks up the table name for that object (’my_things’), then it adds its prefix for that table name (’modx_my_things’), then looks for that table? ’modx_my_things’ doesn’t exist, so xPDO ditches the prefix and tries again, correctly locating the table named ’my_things’? Is that correct?

I think the explanation for this behavior may have something to do with Jason’s related discussion which fielded explanations of run-time vs. design-time differences. I’ve noticed that other MODx packages (e.g. Doodles) simply conform to the defined prefix, e.g. the table name is ’modx_doodles’ and not ’doodles’. That doesn’t seem correct to me for some reason -- I guess I tend to think of the prefix as identifying built-in MODx internals and not my own custom tables.

Sorry if this is unclear, and sorry it’s so lengthy.

You should not include the prefix in your table attributes if you want it to be able to isolate multiple instances in the same database. You can specify the table_prefix at runtime when you call xPDO->setPackage() or xPDO->addPackage(). Otherwise, in the case of the modX class, the prefix specified in the configuration is assumed to apply globally.

Thanks Jason! I stumbled across that part of the API a few hours after I made that post.