<![CDATA[ Using xPDO to reverse engineer existing database - My Forums]]> https://forums.modx.com/thread/?thread=31821 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=3#dis-post-438680
For those who would like to have aggregate/composite relationships automatically. That is under the gun from my side but it ain't that easy. It is doable, but lot more complex than any query build with xPDO to this date. And reason why:

xPDO now supports 3 database platforms officially, add 2 that I've build so we have 5 platforms. If all of these engines would follow ANSI SQL standard this would be piece of cake but each of them has own methods and just even inside the platform itself. Good example is MySQL ISAM vs InnoDB. Where InnoDB actually has foreign key relations and ISAM does not. So to "us" predict the behaviour of foreign key relations with ISAM is impossible.

I was already building this for the Oracle driver when I spend time with it, but it was not as this straight forward even the database does support FK relations. The issues is that when we build xPDO schema, we have Parent to Child relation where parent with composite relation says that "Destroy the children when I am removed" and in SQL world this is reversed. Everything is written to children even the behaviour is the same.

To reverse engineer this behaviour solidly takes time, it is doable but now when there are 5 platforms to support (unofficially) it is really a work to be done. Each of the platforms has their own quirks.

This should have been it's own post to be honest, but wrote here for some reason. I do encourage to use Bob's snippet or read how to write it as an snippet from my site. Just remember that I use $xpdo syntax where MODX users need to use $modx smiley
]]> lazylegs Sep 30, 2012, 03:12 PM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=3#dis-post-438680 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438370 sottwell Sep 27, 2012, 02:10 AM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438370 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438344 Quote from: lossendae at Jan 19, 2011, 07:00 PM


If a user does not need to set any relationship (at the begginning) it can bothersome to him to understand that he have to create an xml files and then parse it and all the "things" behind xPDO.

Maybe I'm misunderstanding you, but there's a snippet here that will create the schema and class files for you: http://bobsguides.com/custom-db-tables.html


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html]]> BobRay Sep 26, 2012, 04:51 PM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438344 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438337
Renaming it to avon_mc and it works fine, go figure...!]]> markvr Sep 26, 2012, 04:31 PM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438337 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438333 I get the following errors when running the script that links here (http://rtfm.modx.com/display/revolution20/Reverse+Engineer+xPDO+Classes+from+Existing+Database+Table) , any ideas?!

PHP Notice: Array to string conversion in D:\websites\avon-mc\core\xpdo\xpdo.class.php on line 439
PHP Stack trace:
PHP 1. {main}() D:\websites\avon-mc\generate_schema.php:0
PHP 2. xPDO->getManager() D:\websites\avon-mc\generate_schema.php:163
PHP 3. xPDO->loadClass() D:\websites\avon-mc\core\xpdo\xpdo.class.php:1207
PHP 4. array_diff_assoc() D:\websites\avon-mc\core\xpdo\xpdo.class.php:439

It doesn't generate any class files or the XML schema.

This is on Revo 2.0.4-pl2 rev7212

Any ideas?! smiley]]> markvr Sep 26, 2012, 03:16 PM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-438333 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-420676
splittingred

Note that the xml schema outputted doesn't define the aggregates/composites (i think it does the indexes, but you'll have to check).

You'll have to define the relationships in the XML yourself. It doesn't take that long, though.
By any chance has this changed? Feeling a bit lazy, but who wouldn't mind a little automation? smiley]]> jobkingori Apr 19, 2012, 12:56 AM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-420676 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172061
If a user does not need to set any relationship (at the begginning) it can bothersome to him to understand that he have to create an xml files and then parse it and all the "things" behind xPDO.
I think that levelling down (?) the access to the API with a simpler method that can be extended for those who need the full capabilities can be good to convince people to jump into the xpdo wagon.

But i understand that it is not a priority since they have ultimately access to native PDO without the need to generate the map classes.]]> lossendae Jan 19, 2011, 01:00 PM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172061 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172060 Quote from: lossendae at Jan 19, 2011, 05:58 PM

Will you provide an easier way/method to generate the package with php only in the future "a la Doctrine" ?
Defining the structure in XML (or maybe JSON or YAML) sounds a lot easier (and more efficient) to me than having to write the code and execute functions at run-time to define the classes/maps. The higher-level representation of the model will be important as we move into features like schema migrations.]]> opengeek Jan 19, 2011, 12:36 PM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172060 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172059 lossendae Jan 19, 2011, 11:58 AM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172059 <![CDATA[Re: Using xPDO to reverse engineer existing database]]> https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172058
NYAHA!

Mr McCormick - once again I bow to your superior eye for detail. It transpires that three of the tables I had copied from elsewhere had a varchar(0) typo in the create statement which I didn’t spot. For some reason MySQL allowed it through.]]> odeclas Jan 19, 2011, 10:48 AM https://forums.modx.com/thread/31821/using-xpdo-to-reverse-engineer-existing-database?page=2#dis-post-172058