elwinar

It works well until you've got an issue, and then you're completely fucked.

I think the sense of the comment was "how can I deploy or test anything once it goes in production". You know, were starting again from scratch is not an option ever.

Using the database as a service layer is dumb for non-trivial scenarios were you need garantees that your service keeps running, or when you want to test new code with the production data.

It's interesting, and probably useful to have a set of functions with the database, but there is real problems once your database stops being a dumb store.

The testing framework of sqitch is pretty cool, I used a something to do database testing a long time ago, but I didn't though of integrating it in the migration tool.

Not exactly a copy, sql-migrate is based on goose, and does many things I don't want rambler to do.

I agree with the easy distribution thing, Go is awesome for this kind of things. I only wish the cross-compilation of binaries that embed C would be easier (XGo is the thing for tkhe moment).

Rambler doesn't have any custom DSL, it use plain SQL. Just like Mite :p

The difference is in the number of features. Rambler doesn't do many thing to keep the overhead low.

Goose does too much IMHO, and sql-migrate is mainly a wrapper around goose. I looked at it for inspiration, but disagreed with many choices.

Migrates is another thing, and I like it more except for the lack of configuration file.

> most migrations don't need to be reversed

I agree, in which case, you don't have to write a down section.

Anyway, rambler isn't targeted at "large companies with huge databases", which of course have more complex database migrations methods.

I've come to drop ORMs altogether in Go, but I will have a look at this one, just out of curiosity.

I had one of those at the very begining, but then I wanted to do things that are more pleasant to do in other languages, so I switched to go. But I can't agree more with your README, my focus stayed on getting out of the way: drop your requests into a file, dump your credentials in a configuration file, run, be done with it.

If you switch you vendor, you will probably have to fix manually many things, be it migrations, code, etc. An ORM-based solution is a thing, but then you lose the ability to use vendor-specific behavior, unless your ORM have specific extension for those, and then you're back at square one.