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?
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.
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.
Which I actually like better. Because it means I can re-use parts of my model like any other code.
Grails does, and it's part of the reason I like it so much.
It does.
"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.
Even if Django wouldn't have such a system yet, nothing would be keeping someone from writing it.
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.