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
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
<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?
Actually, just rememberd createTables did use the custom prefix field. Wished it hadn’t, would have saved a couple of hours of head bashing.
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
&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.
when using the default prefix of your MODX - installation, by default modx_ , you don’t need to specify that
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.
Indeed, its just a cutnpaste from my test to ensure &prefix worked with my renamed table.
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.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.