Maybe we can borrow from the rails world and base this versioning on rake's db migrations[0]? blake hall [0] http://wiki.rubyonrails.org/rails/pages/UsingMigrations On Jun 11, 2007, at 1:24 PM, Philippe Jadin wrote:
I kinda like #2 the best, but #1 may make more sense with our current hook_update_N() system. (#3 has the "advantage" that we might be able to automatically update from one version to the next, but it could also be very complicated.) Perhaps hook_schema_N() and hook_update_N() should be tied together in some way so that the new schema and the upgrade path to get to it from the previous one are always specified together.
Have you considered querying the database to check what fields are already there and add the missing ones based on the latest schema?
The problem is what to do when a field changes type / name between two versions of the schema. But does it happen often?
This would make it very easy for module developpers : simply add the field in the schema, and the schema api take cares of adding the required fields. More complex operations could be handled with #1. We did this with our cms, and it worked great. (this way you have schema versioned like code in cvs). I would not touch the fields found in the DB and not found in the schema, just in case :-)
Philippe
Barry