Added simple migrations support.

[astine]

Hello,

I wrote a very simple skeleton for migrations. This code doesn't do anything automaticly but it does provide the user with the abilty to create migration object, each with an action and a rollback and keeps track of the migrations persistently and in a way which can be edited directly or stored in VC. Hopefully this can be used as a starting point for a more comprehensive system.

Cheers, Andrew

[budu]

Looks good, I'll do a more thorough review and see how it integrate with my plans. Thanks

[budu]

After considering this patch more thoroughly, I won't continue on that path. Here's an overview of what I'm thinking of doing:

I'll probably use simple maps to handle the migrations data as the Clojure reader still doesn't support records and we don't really need polymorphism. The migration stack is a good idea, but I've decided to use a file for this task as we could loose the stack if the JVM is restarted or crash. Also, to know if a migration has been ran, I'll probably use a technique similar to Rails' ActiveRecord where done migrations are kept in a database table. I'll try to make the migrations API extremely simple, with actions handling migrations stacking behind the scene and a single function migrate to execute migrations or roll them back.

Your code is good, but here's some (minor) issues with it:

• In add-migration, it would be better to use conj instead of cons to not assume the underlying data structure is a list.
• The defmigration macro doesn't actually define anything, it's just a front to add-migration, you can see how I do that by looking at the check macro and check* function in the schema namespace for example.

Thanks again!

[budu]

BTW, I'll probably reuse the :do and :undo keys and some other ideas.

[astine]

That's ok. I wrote this as a stop-gap measure for my own use. A few questions though:

I've decided to use a file for this task as we could loose the stack if the JVM is restarted or crash."

My code already (sloppily) ties migrations to a file so I'm confused as to what you plan to do differently. I can see how using the database to store migrations make more sense with respect to a single installation though.

with actions handling migrations stacking behind the scenes and a single function migrate to execute migrations or roll them back.

Do you mean something like:

(migrate ) - to run a migrations (migrate :rollback) - to roll it back?

or do you mean something like: (migrate) - to run unrun migrations and (migrate :rollback <number of migrations or migration point to which to roll back>) - to roll them back

The later makes more sense to me though I prefer seperately named (migrate) and (rollback) functions.

On Wed, Apr 20, 2011 at 5:01 PM, budu reply@reply.github.com wrote:

After considering this patch more thoroughly, I won't continue on that path. Here's an overview of what I'm thinking of doing:

I'll probably use simple maps to handle the migrations data as the Clojure reader still doesn't support records and we don't really need polymorphism. The migration stack is a good idea, but I've decided to use a file for this task as we could loose the stack if the JVM is restarted or crash. Also, to know if a migration has been ran, I'll probably use a technique similar to Rails' ActiveRecord where done migrations are kept in a database table. I'll try to make the migrations API extremely simple, with actions handling migrations stacking behind the scene and a single function migrate to execute migrations or roll them back.

Your code is good, but here's some (minor) issues with it:

 * In add-migration, it would be better to use conj instead of cons to not assume the underlying data structure is a list.  * The defmigration macro doesn't actually define anything, it's just a front to add-migration, you can see how I do that by looking at the check macro and check* function in the schema namespace for example.

Thanks again!

Reply to this email directly or view it on GitHub: https://github.com/budu/lobos/pull/3#issuecomment-1035920

[budu]

My code already (sloppily) ties migrations to a file so I'm confused as to what you plan to do differently. I can see how using the database to store migrations make more sense with respect to a single installation though.

I think I've misunderstood the stack code. I was thinking about stacking actions before committing them to a migration file. Say you're at the REPL and perform a bunch of actions on a database, these actions will be temporarily stored inside a file that you can later dump into one or multiple migration file.

For your stack code, I'll have a second look at it, but I think of doing something simpler based on diffing the migrations file names against the migrations table.

Do you mean something like...

More like the second example, I've just updated the Migrations wiki page to include a preview of the migrate action API.

[astine]

I personally don't like APIs which use a single function to do the job of several. It reminds me of bad Java APIs (and one notorious CL one,) but so long a one can reasonably store a migrations history in VCS and use that data to keep multiple databases in sync I'll be happy.

Regards

On Wed, Apr 20, 2011 at 5:50 PM, budu reply@reply.github.com wrote:

My code already (sloppily) ties migrations to a file so I'm confused as to what you plan to do differently. I can see how using the database to store migrations make more sense with respect to a single installation though.

I think I've misunderstood the stack code. I was thinking about stacking actions before committing them to a migration file. Say you're at the REPL and perform a bunch of actions on a database, these actions will be temporarily stored inside a file that you can later dump into one or multiple migration file.

For your stack code, I'll have a second look at it, but I think of doing something simpler based on diffing the migrations file names against the migrations table.

Do you mean something like...

More like the second example, I've just updated the Migrations wiki page to include a preview of the migrate action API.

Reply to this email directly or view it on GitHub: https://github.com/budu/lobos/pull/3#issuecomment-1036289

[budu]

I'll think about it.