BTW, Java is a much better (in most ways) product line than PHP, more rigorous, and Roo is a much more powerful tool than many other similar tools (like Ruby on Rails and Symfony, CakePHP, et al). I’m most familiar with Symfony, I’ll admit.

From what I’ve seen, Symfony/Doctrine always had problems with introspection on anthing but MySQL. It would work . . . on simple stuff. Personally, I expect Roo to do a better job, BUT, complex databases are hard to translate into ORMs. I think hooking into the existing database as I’ve described might be better, and using Eclipse JPA (with what little I’ve read about that).

Another solution is to build an equivalent Roo version, export your database, reimport it into the new design, using SQL and POJ, (Plain Old Java/PHP). Now that I think about it, that’s what I did with my PHP project. It means, as usual in the database world, if you change your schema, be prepared to do a LOT of work.

have you looked at this again? I ask because there are still problems with SpringRoo and version fields when reverse engineering.

I can, for example, reverse engineer a database with SpringRoo, but it falls over when generating a GWT web framework saying that it *needs* a version field.

This is a pain when I have an existing schema I can’t easily change.