I can give you many reasons and many details, but I know you will not agree
with my conclusions. I remember what you (or someone from the team) said
about my ideas. I've shared them already and someone told me why you've
decided to do it that way, and why you wouldn't change it. I'm respecting
your visions and ideas, but they are becoming more and more distant from
mine. And it is OK until you're introducing obstacles (from my perspective,
just a regular user). Removing daily used tool is an obstacle, believe me.
Let's back to the migrations. They are very sensitive to Python imports,
dependencies, and used objects. Some time ago I've got a project to
rescue, where deps were poorly managed and the code was trashy. After
cleaning up, some apps couldn't migrate and Django was creating initial
migration instead of adding migration with differences. If I remember the
problem was related to some import error or some missing object. But it
does not matter here. The worst thing was that Django skipped all
migrations and tried to do somenthing unplanned, something that could
damage the database, and something that damaged initial migration file.
Just because some old and already applied migration has an some python
error. And this is practically uncontrollable and unreliable behavior.
What output will generate `sql` command based on schema migrations in such
case? Should it really be dependent on the complicated system, where it is
created to translate current state of model's metadata to DDL? I don't
think so. I agree with you that there should be one way to do something.
But I'm not sure that the results and use cases of "sql*" commands are same
as for migrations.
Schema changes are about adding, removing or altering something in the
database. Application layer issues shouldn't affect the sequence of DDL
changes. Migration system can be written in Python (as a part of Django),
but changesets should not be dependent on any part of an application layer.
There is a one fundamental reason for this approach - the application layer
is chagning more often than the database (both for schema and data). That's
why it is so important for long-term projects. I don't like saying that,
but for my 16 yr pro experience I saw this rule almost in every system.
Then look at Django which is forcing you to use it's migrations, highly
coupled with application layer, sometimes failing, and "owning" my
old-and-very-important database... Do you understand now why I'm suggesting
Django (from 1.7+) for short-term and smaller (simpler in terms of a
complexity) systems? I'm not saying that they are completely wrong. They
have advantages and the most I like is autodetection of model changes.
`sql*` commands were decent tools for translating model metadata to DDL. It
was very handy to prototype the app layer and generate DDL. Then DDL was
used directly in db schema management system. In this scenario we aren't
talking about creating Django' migrations, especially not about tracking
model changes. "sql*" commands were always releated to the current schema,
so there is no necessity to change this. So whenever I'm talking about
"sql*" command, I'm thinking about model's current schema and similar use
cases. I'm asking myself again: Should it be dependent on the migration
system? What benefits it will give? Is it worth implementing simple
function based on such complicated migration engine? How much it will cost?
Who will use it?
The reason of removing two differenct ways of managing db schema is clear
for me. I just do not understand removing the tool without providing decent
replacement for it. For example, CBV generics were replacement for FBV
generics. There was an incompatibility in the interface, but the generic
views functionality was saved. For "sql*" commands there is no replacement.
I think that you're assuming that builtin migrations covers all use cases
and you aren't worrying about projects, where migrations aren't used. I
understand this, but it narrows the flexibility of Django.
Believe me or not... Whenever fellows asks me "what instead of Django?",
I'm answering - Django. I'm pointing (not disparaging) weakness just
because I care and because I'm using Django for a very long time. Django
is good, but may be better. I would like to contribute and make it better,
but I'm afraid that my ideas would be dropped due to some kind of "Django
ethos". The most counter productive for me is rejecting the idea, then
implementing it after X years. It was happened few times for me and I don't
fully understand that.
I'm with Django from v0.96. The things went little wrong starting from 1.7,
IMO. Some guys on this forum told me, that I'm using Django bad way and it
is possible that Django does not fit my needs. I can agree, but older
versions were fitting my needs pretty well. My needs are still same, so
what's happened? As a result I'm just giving advices like "do not use
Django in such project[, because it would not fit your needs]", same as
others gave me. I'm not polite? Could be. When you're forced to di
something "wrong" way, or when you're kicked out ("stay with 1.4"), and
when you can't move away, you can feel a little irritated. I'm sorry about
that. Honestly.
Please don't get this personally and do not treat this as a complains. I've
just wanted to share my POV.
I'll pick up your suggestions about being more constructive.
Marcin
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/02c2a321-313d-4848-9417-2b0c708fefd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
