Hacker News Reader

Comment by hartator | Hacker News Reader

If you are using something like Mongoid, you are declaring the schema only once directly in your rails app. How having your schema burried in migrations - however clean they are - is superior?

View on HN

In Rails, your schema isn't buried in migrations. You seem to be lacking a whole bunch of knowledge about this subject in general, maybe tone it down with the hyperbole?

Here's your schema from Postgres:

    pg_dump -s your_db | less

Or you can explore it using `psql`:

    $ psql your_db

List schemas:

    your_db=# \dn

List tables in a schema:

    your_db=# \dt public.

Show table detailed info (constraints, indexes, comments, etc.):

    your_db=# \dt+ your_table

List functions:

    your_db=# \df

Or you can install pgAdmin and browse through the entire database--tables, constraints, indexes, the whole shebang--in a single screen. At no point are the migrations burying the schema. That's just a fundamental misunderstanding of how to work with databases.

That's not what I'm saying, I'm saying use an ORM that does not rely on migrations to form the schema. I can't think of a single one that does.

I don't get it. Isn't any good SQL ORM provide their own DSLs for migrations?

Yes. Look, take for example the Django ORM. You specify the models in a python file. These are the central source of truth for what your database tables look like. If you want to add a column or change something in the schema you then generate the migrations from that.

The migrations don't drive your schema, the schema drives the migrations. Proper tools don't make you have a bunch of .SQL files that organise your database.

Devil's advocate - how is it really better to have a bunch of autogenerated Django migration files?

Better than what?

Can the Django ORM support migrations of stored procs, custom types, and other non-tabular entities?

Reply on news.ycombinator.com