YASB – Yet Another Symfony Blog

May 9, 2007

Solved: How to get I18n working on reverse-engineered tables

Filed under: Database, PHP, Propel — Krof Drakula @ 12:24 pm

We’ve all been there – Symfony and I18n do play well together – it’s got XLIFF for interface translation which works almost out-of-the-box, it’s got localization features for things like numbers, currencies and many others. It also has internationalization features that work with database tables.

Unfortunately, all is well until you stray from the guidelines presented in the Symfony book. The norm in Symfony is to write the database definition withing the schema.yml file. That’s okay… it’s compact, concise and verbose enough to be understood within the context of Symfony nomenclature. But when you’re dealing with 25+ tables that need accompanying I18n tables, things could get messy, nomenclature or not.

Fortunately, we’ve found a cure. The problem lies in Symfony not assuming this nomenclature when reverse-engineering the schema.yml file from the database. Sure, foreign keys and reference definitions do get solved, but Symfony does not make the effort of looking for matching tables.

And since I18n is in the domain of schema.yml file and not Propel, we found a way to get those tables working after all by creating a new Pake task that does this for us: patch-db-i18n.

A typical development cycle takes the form of the following four steps:

[sync the database]
symfony propel-build-schema
symfony patch-db-i18n {application} [{suffix} [{column}]]
symfony propel-build-model

This way, we let Symfony generate schema.yml for us, then take the YAML file and patch it using the appropriate _attributes and column settings to enable I18n on the tables. Since the database doesn’t need to know about the I18n attributes, we don’t need to re-insert the SQL, but rather only regenerate the model.

To get this delicious piece of code, have a look at the accompanying wiki page in the Symfony wiki.

This is the first step in trying to streamline an external database build tool into the development chain. The next step will be to make a string of tasks that will take the source XML from a visual developer tool (like DBDesigner4) and try to sync the database, reverse-engineer it, apply I18n rules to the resulting YAML, rebuild the model and clear the cache.

Eventually, integrating a revisioning system similar to the one in Rails would be perfect, since you could have a snapshot of the database coupled with the revision in which you commit including the model layer. And checking out a revision would be as simple as checking out a specific revision from SVN and rebuilding the environment from the revision itself, including the necessary databases and the model (which would then not even need to be built, now that I think of it).

Ah, maybe next week. Now, more coffee.

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress