Ruby-style migrations are great but, as others have said, they lend themselves better to another layer of abstraction. I was thinking of a lower-level alternative to migration. We could find a way to construct an ast from the current database schema and then compare it with the one generated by the create-table macro. Another macro could generate the alter clauses to migrate the differences between both. This option too should be considered only after version 1.0 is release as it's not trivial to implement.
On Dec 11, 4:40 pm, rb <raphi...@gmail.com> wrote: > > > And a suggestion: having migrations in CQL would be great! > > > Could you elaborate a little? > > Migrations are a way to manage the evolution of a schema of a > database. I'm familiar with migration in Ruby on Rails which are > explained here:http://api.rubyonrails.org/classes/ActiveRecord/Migration.html > > All changes to the data schema are made with migrations that, when > applied (in the right order), build your database. You can also > possibly go back and undo the change if the operation was not > destructive (migrations have an up- and downgrade operation). The list > of migrations applied are kept in a table of the database, so when an > upgrade is done, the migration system knows which migrations have to > be run in the upgrade step. When a migration is run, its id is added > to the list of migrations that have been applied to the database. And > when a migration is unapplied (downgrade operation), its id is removed > from the list. That way, you can go up and down in the version of your > schema. Of course you most often only play with the last migrations > during the development phase. And when you deploy to production, you > may be sure the same changes will be applied as what you did. > > And migration can also manipulate the data in addition to change the > data structure. For example, it can create and populate a table with > initial data. In an extreme case, if you want to split a table in > multiple tables, you could do that in a migration which would > - create the new tables > - populate them with data from the initial table > - drop columns that are now superfluous in the initial table > These operation can be non-destructive, and so the migration can be > undone. > > It's really been a time saver and I think it's a really good fit with > ClojureQL. > > Raphaël -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
