3 ms·

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 - howev

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?

orf 10y ago
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.
- hartator 10y ago
  I don't get it. Isn't any good SQL ORM provide their own DSLs for migrations?
  - orf 10y ago
    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.
    - pekk 10y ago
      Devil's advocate - how is it really better to have a bunch of autogenerated Django migration files?
      - orf 10y ago
        Better than what?
    - yawaramin 10y ago
      Can the Django ORM support migrations of stored procs, custom types, and other non-tabular entities?
evilduck 10y ago
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?
yawaramin 10y ago
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.

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?

orf 10y ago

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.

hartator 10y ago
I don't get it. Isn't any good SQL ORM provide their own DSLs for migrations?
- orf 10y ago
  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.
  - pekk 10y ago
    Devil's advocate - how is it really better to have a bunch of autogenerated Django migration files?
    - orf 10y ago
      Better than what?
  - yawaramin 10y ago
    Can the Django ORM support migrations of stored procs, custom types, and other non-tabular entities?

evilduck 10y ago

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?

yawaramin 10y ago

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.