Hacker News new | past | comments | ask | show | jobs | submit login

doesn't diminish this particular feature

Well, this particular feature is a bandaid for an underlying misfeature (manual schema management).

Proposing this as good practice is somewhat akin to proposing "If you design a new operating system then make sure the installation of virus scanners is as easy as on Microsoft Windows".

You may call it a strawman, I'd call it "putting something into perspective".

Besides, the schema-migration has very little to do with the ORM, except for the fact that they both interact with a database.

That's a nice theory but in practice most rails users do use the builtin migration mechanism, for the lack of a better alternative (at least to my knowledge, feel free to correct me).

Consequently I don't think it's unfair to compare that mechanism to the equivalent in similar frameworks - and in that comparison rails loses, big time.




"Well, this particular feature is a bandaid for an underlying misfeature (manual schema management)."

Could you expand on that? Maybe I'm missing something here.


Well, I was aiming at the "learn from rails" part.

The explicit mention of rails just stuck out to me (probably more than the author intended), as if rails had achieved something extra-ordinarily smart there. - While to me it's just an implementation detail of an otherwise rather inferior approach.

Modern schema migration tools compute the difference between the current and the desired state on-the-fly, and generate the migration commands accordingly. Explicit version numbers/timestamps/hashes are mostly used for documentation and transparency purposes there, not for the sake of conflict resolution.

These algorithms are naturally not flawless, but they work well for the proverbial 90% of cases. In such an environment the user doesn't normally have to futz with migration scripts or migration version-numbers at all.


Modern schema migration tools?

Please list those widely used modern schema migration tools as they occur in other popular languages like PHP, Python, Perl, and so on.

In rails, users don't futz with migration version numbers. Those are handled automatically by the system. The user simply specifies a migration, e.g. "I want to add this column to this table." The migration is then automatically run when doing the next deployment. That doesn't work in 90% of the cases - it works in 100% of the cases.

Woe be unto the developer whose deployment process only works 90% of the time.


Please list

I already did in another comment but I'll repeat: django south, hibernate schemaupgrade, datamapper automigrate, postfacto (standalone python/postgres), sqlalchemy-migrate

e.g. "I want to add this column to this table."

The difference is that in Rails the user has to update the model and create a matching migration. In most other frameworks the second part is strictly optional and by default implicit.

Woe be unto the developer whose deployment process only works 90% of the time.

That's not what happens. In practice there's always a review step.

However, I've already been accused of strawmanning, so rather than taking this further offtopic let me just point you to http://south.aeracode.org/docs/tutorial/part1.html


At least several, maybe all, of those were directly inspired by rails migrations. Whether something automatic, but imperfect (renames, anyone?) is actually better than something explicit but easy enough seems a matter of taste.


At least several, maybe all, of those were directly inspired by rails migrations.

Actually most of them (except datamapper and postfacto) have existed before rails was created.

And I'll argue strongly against "matter of taste" when it comes to error-prone routine procedures.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: