In principal yes, although the code actually doing the migrations looks much more 'procedural' than in RoR. That's mainly because RoR uses Ruby syntax tricks heavily in migrations to make them look more like 'config' files. I'd assume Rails migrations were a big inspiration for that proposal because of the similarities and the 2 references to RoR migrations in the reference section. ;)
This is a decent reproduction of Rails migrations AFAIC see, but I think we could aim higher (or at least more flexible?) in ZF. ,Wil From: Simon Mundy [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 6:24 PM To: Wil Sinclair Cc: Sander van de Graaf; Zend Framework - General Subject: Re: [fw-general] db migrations I don't know RoR at all but is this similar to the proposal on the wiki for Zend_Db_Schema_Manager? - http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+R ob+Allen Hi Sander, I've put some thought in to db migrations because it was a part of RoR that I both really liked and found somewhat over-simplified. On the one hand, I thought the RoR implementation was an elegant way to version application schemas and it lent a helpful tool to a pretty vital best practice. On the other, I felt that the ruby-based DDL abstraction was rather toy-like and one would quickly revert to 'execute' and standard SQL DDL/DML in real environments. Admittedly, I haven't tested the limits of db:migrations, but the differences in ddl among- and in the objects that can be created in- different DB's combined with the relatively minor savings in complexity and database 'independence' left me less impressed than with other parts of RoR. As always, I'd love to hear about other opinions and experiences with different frameworks. For ZF, my current preference would be for raw sql-script-based migrations with the possibility of supporting or providing extensibility for future support of files and possibly other non-code application artifacts. Basically it would aim to be a simple versioning/environment setup tool that is much easier to use- but no less powerful than- shell scripts. Questions that I haven't fully thought through include: Should we support only one usage pattern over others- like sequential versioning over schema management simplification/separation? Would it be feasible to generate raw sql-scripts if we decide we'd like to do that in the future, or would we rather be generating a sort of 'intermediate language' much like RoR migrations? Are there any useful integration points with CVS/SVN? And the list goes on and on. . . Right now I'm putting together a proposal for a CLI tool that (hopefully) reflects some of the best ideas out there but doesn't skimp on flexibility. I would love to see someone working off the draft proposal to provide migrations. ;) ,Wil -----Original Message----- From: Sander van de Graaf [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 2:38 PM To: Zend Framework - General Subject: [fw-general] db migrations Hi! I was wondering if someone has any thoughts on db migrations in combination with ZF. I have some great deployment scripts ready for pushing out my application code, but I was wondering how to get db migrations up and running in an easy way. I have looked at the Cake db migrations, but it's too much mixed with the Cake console. I also looked at liquibase (liquibase.org), but it has a pretty bloated xml config, and I prefer some sort of yaml or perhaps sql migrations. Anyone any ideas or suggestions? -- cheers! Sander van de Graaf -- Simon Mundy | Director | PEPTOLAB """ " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" " Please support Movember today! Visit http://www.movember.com/au/donate Registration number for Simon 160725 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000 Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124 http://www.peptolab.com
