4 ms·

Can you elaborate on the non-declarative schema point? With something like Django's South handling migrations, what problems does the declarative schema introdu

Can you elaborate on the non-declarative schema point? With something like Django's South handling migrations, what problems does the declarative schema introduce that Rails side-steps?

snprbob86 16y ago
I wrote about this here: http://blog.brandonbloom.name/2009/10/orms-and-declarative-schemas.html http://blog.brandonbloom.name/2009/10/orms-and-declarative-s... It is a subtle, but fundamental distinction: Django expects me to declare my schema in Python. Rails (and optionally SqlAlchemy, which I like) operate via schema reflection. The declarative approach is redundant, error prone, and resistent to migrations, even with South. The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment.
- Pewpewarrows 16y ago
  The declarative approach is only redundant if you're inheriting a project, and even then it's only redundant that first time you mirror the existing db schema in Python. How can you call a declarative method redundant and not schema reflection? They're reverse processes of the exact same thing. The only "errors" I can think of that can arise from declarative over reflection is when someone decides to manually fuck with your database while ignoring your framework's tools. And even then, South basically handles every use case. How exactly do you think South is resistant to migrations? Updating your models.py and running two manage.py commands seems pretty damn straightforward to me. "The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment." So, you're saying that because one way looks like what you were doing before a framework, it's somehow "better?" What kind of backwards logic is that? It's basically the definition of abstraction.
- phaylon 16y ago
  Sounds like what's missing is the ability to create the schema from the declared code. Which I actually like better. Because it means I can re-use parts of my model like any other code.
  - mgkimsal 16y ago
    I thought django had that. ??? Grails does, and it's part of the reason I like it so much.
    - xiongchiamiov 16y ago
      > I thought django had that. ??? It does.
      - mgkimsal 16y ago
        The parent poster wrote "Sounds like what's missing is the ability to create the schema from the declared code." Which is what I was questioning. I thought (rightly) Django had that functionality.
        phaylon 16y ago
        I don't use Django and so I simply didn't know. From the description it just sounded like such a solution would fit the problem. Even if Django wouldn't have such a system yet, nothing would be keeping someone from writing it.
- ubercore 16y ago
  Having used both (though Django much more heavily) I don't see any practical differences between migrations in a non-declarative system (Rails) and a declarative one (Django). Migrations are always a bit of a pain, but database changes (at least to any field managed by a framework) will almost always require code changes -- so what are you gaining by leaving the field declaration out of the model? I'd say that the declarative syntax is actually a bonus. It makes the code much more discoverable, and I haven't seen a real downside.
- deleted 16y ago
  [deleted]
- duke_sam 16y ago
  I understand the need to have the schema where it's being used but if you ever need to make modifications like custom fields (say an email field) then your schema isn't just stored in the DB any more. With Django your custom field declarations live in the same place as more mundane fields. If you port that models file to another machine and run syncdb you are going to be left with the same schema with the same restrictions.

Can you elaborate on the non-declarative schema point? With something like Django's South handling migrations, what problems does the declarative schema introduce that Rails side-steps?

snprbob86 16y ago

I wrote about this here: http://blog.brandonbloom.name/2009/10/orms-and-declarative-schemas.html http://blog.brandonbloom.name/2009/10/orms-and-declarative-s... It is a subtle, but fundamental distinction: Django expects me to declare my schema in Python. Rails (and optionally SqlAlchemy, which I like) operate via schema reflection. The declarative approach is redundant, error prone, and resistent to migrations, even with South. The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment.

Pewpewarrows 16y ago
The declarative approach is only redundant if you're inheriting a project, and even then it's only redundant that first time you mirror the existing db schema in Python. How can you call a declarative method redundant and not schema reflection? They're reverse processes of the exact same thing. The only "errors" I can think of that can arise from declarative over reflection is when someone decides to manually fuck with your database while ignoring your framework's tools. And even then, South basically handles every use case. How exactly do you think South is resistant to migrations? Updating your models.py and running two manage.py commands seems pretty damn straightforward to me. "The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment." So, you're saying that because one way looks like what you were doing before a framework, it's somehow "better?" What kind of backwards logic is that? It's basically the definition of abstraction.
phaylon 16y ago
Sounds like what's missing is the ability to create the schema from the declared code. Which I actually like better. Because it means I can re-use parts of my model like any other code.
- mgkimsal 16y ago
  I thought django had that. ??? Grails does, and it's part of the reason I like it so much.
  - xiongchiamiov 16y ago
    > I thought django had that. ??? It does.
    - mgkimsal 16y ago
      The parent poster wrote "Sounds like what's missing is the ability to create the schema from the declared code." Which is what I was questioning. I thought (rightly) Django had that functionality.
      - phaylon 16y ago
        I don't use Django and so I simply didn't know. From the description it just sounded like such a solution would fit the problem. Even if Django wouldn't have such a system yet, nothing would be keeping someone from writing it.
ubercore 16y ago
Having used both (though Django much more heavily) I don't see any practical differences between migrations in a non-declarative system (Rails) and a declarative one (Django). Migrations are always a bit of a pain, but database changes (at least to any field managed by a framework) will almost always require code changes -- so what are you gaining by leaving the field declaration out of the model? I'd say that the declarative syntax is actually a bonus. It makes the code much more discoverable, and I haven't seen a real downside.
deleted 16y ago
[deleted]
duke_sam 16y ago
I understand the need to have the schema where it's being used but if you ever need to make modifications like custom fields (say an email field) then your schema isn't just stored in the DB any more. With Django your custom field declarations live in the same place as more mundane fields. If you port that models file to another machine and run syncdb you are going to be left with the same schema with the same restrictions.