MIGXdb Table Custom Prefix Not Used Properly?

Support Extras
1

Modx 2.7.1 MIGX 2.12.0

Problem: Custom Prefix for Table is ignored. So a migxLoopCollection always fails until table is renamed via PHPMyAdmin to modx_sometablename

Process
Adding a Custom Table for some database activities.
As is customary I thought I’d use a custom prefix, say, myprefix_ so as to make it clear it isn’t a modx_ table.

Went through the process in the MIGX Extra (shouldn’t this be called MIGXdb in the menu?)
Package Name to Test
set table-prefix for a custom prefix and entered a custom prefix e.g. myprefix_

Create Package. Then root around in Filezilla finding
~/core/components/Test/model/schemaTest.mysql.schema.xml

Contains:
<model package="Test" baseClass="xPDOObject" platform="mysql" defaultEngine="MyISAM" phpdoc-package="" phpdoc-subpackage="" version="1.1">

But I think it should contain tablePrefix=“myprefix_”

As there is no mention of a prefix all else goes wrong. parseSchema, CreateTables etc: their outputs have no mention of myprefix_
And of course migxLoopCollection fails - and silently. Tried everything to get it to work but in desperation renamed the table and jackpot - my handedited data appeared on my webpage from the custom database table.

I wonder if the few who use the MIGXdb never use the prefix? So it’s never been spotted.

A bug or have I missed something?

Stuart

2

Actually, just rememberd createTables did use the custom prefix field. Wished it hadn’t, would have saved a couple of hours of head bashing.

3

I very seldom use custom prefixes.

But if you do so, you allways have to tell, that you do so, at all migxLoopCollection - calls or at the manager - actions

4

Thanks Bruno.

[[!migxLoopCollection?
&packageName=test
&classname=Test
&prefix=modx_
]]

&prefix did the trick - doesn’t seem to be documented. Suggests nobody uses custom prefix table names. Thought it would be the done thing. Hopefully this helps someone else.

Cheers

5

when using the default prefix of your MODX - installation, by default modx_ , you don’t need to specify that

6

I’d like to also recommend not to use custom prefixes. The modx_ prefix is only a default, and the idea of prefixes is that you can have multiple MODX installations (or even different CMSes) in a single database table. By using a custom prefix, you remove that flexibility.

Instead, prefix the object tables with what you like. Maybe <object class="Test" table="mycmp_test" extends="xPDOSimpleObject">...</object>. It will then be created as modx_mycmp_test which is sufficiently prefixed to avoid conflicts, while keeping the flexibility of the MODX prefix.

7

Indeed, its just a cutnpaste from my test to ensure &prefix worked with my renamed table.

8

I see @markh - in other words keep the custom table associated with that installation of modx (as opposed to something else in the database).
I’m building a Weather History application. Taking 20 years or so of DarkskyAPI wind direction, speed and gusts etc for my town and storing them in a database. Which could be 7300 rows. Then use chartjs or d3 or something to plot a radar chart of winddirection and speed for e.g. Every July since 2000. Just for fun and to practice MIGx and XPDO and charting.

And probably not a big deal but was thinking that with a different prefix it would be easier to only backup my modx_ tables and not always backup my weather data. I’ve just found backupMODx (where has that been all my life). Not sure if it ignores non modx_ tables.
And I’m too scared to try the different database approach.
I’ll figure something out.

Thanks