Migration suggestion

[James Reeves]

I've been trying out the migrations in Lobos 0.8.0, and I'm finding parts of the library design perhaps a little unintuitive.

One of the things that confused me is that migrations only work if they're defined in a namespace called "lobos.migrations". This seems a little unidiomatic.

Instead of this, what if migrations were local to a particular namespace? i.e. something like:

  (ns my.app.migrations

    (:use lobos.migration))

  (defmigration create-user

    (up ...)

    (down ...))

One could then write:

  (migrate db 'my.app.migrations)

If this seems okay, I can implement this behaviour and send off a pull request.

- James

[Nicolas Buduroi]

Good idea, currently there's support for another namespace using the lobos.migration/*migrations-namespace* variable, but it would certainly be better with an explicit argument.

I won't have time to work on Lobos for at least two more weeks, so I would be glad if you can send me a pull request.

Thanks

[James Reeves]

I started experimenting with migrations in Lobos, but as I did I came
to the conclusion that migrations do not necessarily have to be tied
tightly to SQL databases. In theory, migration support is useful for
transforming any structured data.

As I'm a big fan of factoring things out when possible, I've started
work on a database independent migration library called Ragtime. It
doesn't have functionality for manipulating databases, so would it
would need to be used with a database-manipulation library like Lobos.

I'm not sure what direction you want to take with migrations in Lobos,
but I thought I'd keep you informed of what I'm working on, regarding
migrations.

- James

[Nicolas Buduroi]

That looks like an interesting project!

[Phil Hagelberg]

On Nov 27, 4:19 pm, James Reeves <jree...@weavejester.com> wrote:
> I started experimenting with migrations in Lobos, but as I did I came
> to the conclusion that migrations do not necessarily have to be tied
> tightly to SQL databases. In theory, migration support is useful for
> transforming any structured data.

That sounds an awful lot like Drift: https://github.com/macourtney/drift

Have you considered drift and found it wanting? It's missing all the
nuts-and-bolts that Lobos seems to provide, but they do already seem
very complimentary.

-Phil

[James Reeves]

On 29 November 2011 00:06, Phil Hagelberg <ph...@hagelb.org> wrote:
> That sounds an awful lot like Drift: https://github.com/macourtney/drift
>
> Have you considered drift and found it wanting? It's missing all the
> nuts-and-bolts that Lobos seems to provide, but they do already seem
> very complimentary.

I started work on migrations before I knew about Drift, but there are
a few things in Drift I don't like.

I don't like having a migration per file. I'd prefer to put my
migrations in a single file.

I'm also not sold on having a migration per namespace. At first I
thought that a Migration protocol would be a better solution, but
since I've talked to you and hiredman on #clojure, I'm beginning to
think that the best way of representing a migration is via a map:

{:up #(alter :add (table :users (column :email (data-type :varchar 255))))
:down #(alter :drop (table :users (column :email)))}

The advantage of this approach is that we can use functions to
generate migrations:

(defn add-column [tbl-name col-name & definition]
{:up #(alter :add (table tbl-name (apply column col-name definition)))
:down #(alter :drop (table tbl-name (column col-name)))})

So then the migration becomes:

(add-column :users :email (data-type :varchar 255))

- James