> Please don't get me wrong. I have worked with RDBMS for more than a
> decade but I alse use django-nonrel with MongoDB on a daily basis. I
> also think that the approach django-mongokit takes is much more
> natural for NoSQL data than just reusing the ORM. The ORM has no way
> to express complex structures and if such support is added, you will
> always have to choose which subset to use. For relational tables you'd
> get foreign keys and for non-relational you'd get structure semantics.
> Then we have the ModelForms that would need to start producing
> sub-formsets for certain structures. In the end you end up with one
> swiss army knife instead of a fork and a knife. While possible, it's
> not very convenient to dine using a swiss army knife.
>
> --
> Patryk Zawadzki
> I solve problems.

You do make a good point.  It's not just that NoSQL systems lack
features (transactions, schema, relations) that are common to SQL-
based systems; it is also the case that non-relational systems have
additional features that are missing from many relational databases.
Either the ORM will have to ignore those features, or it will
implement them in a way that risks being convoluted and imperfect.

But what is wrong with the ORM ignoring features that would risk
making it convoluted?  Already there are dozens, maybe hundreds of
features of Oracle (including features that are NoSQL-like, like
object tables and hierarchical queries) that are not implemented in
the Django ORM, and that's OK.  There are a number of specialized
fields in Postgres that are not officially supported, some that are
also NoSQL-like (array fields, for instance).  Even aggregation wasn't
supported at all by the ORM until version 1.1.  The ORM is already
making these kinds of choices in order to provide a standardized
interface that can be reused without modification; anyone who needs
these features can use them outside the ORM, or can extend the ORM.

There is a place in the world for swiss army knives.  Among the big
selling points that Django has are its contrib apps and its pluggable
third-party apps.  The admin contrib app is a headline feature of the
framework; I would call the admin a swiss army knife.  There's nothing
wrong with being a swiss army knife, it seems to be part of the
framework's objectives.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to