Migrating from MySQL Workbench to ORM Designer
As you probably know, we use(d) MySQL Workbench for all our database design needs. We used the PropelExport Plugin to export the schema to a Propel-compatible schema representation. Unfortunatly our plugin could only export the basic tables and relations, but since Workbench does not know anything about Propel behaviors etc. we had an additional php-script that would patch (merge) the schema.xml generated from our plugin with some additional tags and attributes that PropelExport-Plugin did not support.
Since we started development on DiLoc 2.0 we wanted to refactor some parts of our database-propel layer and ExtJS integration. For this to work we needed some additional custom fields in schema.xml (because we generate ExtJS Frontend Models automatically from schema.xml). Putting even more stuff (like validations which we wanted to define only once in schema.xml in our updated framework) into into our schema_addon.xml felt more and more wrong. As I heard of ORM Designer before, it was time to evaluate if ORM Designer could replace MySQL Workbench in our workflow.
On our first try I was quite underwhelmed because ORM Designer did not support Propel-validations, the prime feature we wanted to use it for. I asked the developers of ORM Designer if support for validations could be added, and provided some links for documentation about how validations work with Propel. – Lo and behold, on the same day a new beta version of ORM Designer was made available for us. – Even including a lengthy blog-post explaining the new features. I tried it out and it worked perfectly. Since ORM Designer is very extensible, we even got a config file extending tables and columns with new attributes we needed to generate frontend-models from schema.xml. I was very happy and tried adding behaviors to our tables, only to find out that behaviors where only supported for Doctrine in ORM Designer. – But no Problem, after some emails back and forth between me and the developers, we got a shiny new version supporting all Propel 1.6 behaviors, even with all available parameters and so on! – Great! During this, the developers where extremely friendly and interested in implementing the things we needed. They also provided us extended testing-licenses so we could test ORM Designer some more.
So now we can design our database schema with ORM Designer and can directly add all needed fields and attributes to our tables, columns, etc. and directly export to a fully Propel 1.6 compatible schema.xml. We dumped our handwritten schema-patcher and even added an additional attribute to all columns that we needed.
ORM Designer with validators and our custom fields.
ORM Designer lets us even enhance schema.xml in the future should the need arise. We feel confident in having found the right tool for our needs. The only missing point when coming from MySQL Workbench, is that you cannot have multiple “diagrams” that showed your tables. This allows you to add custom diagrams for parts of your schema, where you only need some tables. This allows you to break your schema in parts and print out nice overviews on parts of the schema only. ORM Designer allows you to group tables into regions, but all relations to related tables are always shown, even if they go outside a region. In this regard Workbench is more flexible, even providing different relation-notation styles, etc. So ORM Designer is really really great on directly working with the ORM of your choice (Propel, Doctrine, Doctrine2,CakePHP, Symfony), and is really customizable for importing, exporting, and adding custom fields. This is really cool. But on the side of visualizing your schema, Workbench has still the edge over ORM Designer. Here is hope that the developers of ORM Desinger catch up in this area.
We urge you to try out the current Beta-Release (which is extremely stable) of ORM Designer! It has really great Propel 1.6 support, including all Propel-table and column-attributes, behaviors, validations, etc. And even if some feature you need is missing, chances are high that they are able/willing to implement it for you. This is in high contrast to MySQL Workbench where custom development would be unthinkable I believe.
