W dniu wtorek, 4 lipca 2017 23:49:54 UTC+2 użytkownik Carl Meyer napisał:
>
> On 07/04/2017 07:04 AM, Patryk Zawadzki wrote:
> > Have DB backends understand certain field types expressed as strings
> > ("varchar", "text", "blob", "decimal" and so on).
> >
> > Possibly some backends could implement a wider set than the others
> > ("json", "xml", "rasterimage" etc.).
> >
> > Have each Field class deconstruct to a field name and params, eg:
> > "decimal", {"digits": 12, "decimals": 2}.
> >
> > Then a model becomes essentially a list of tuples:
> >
> > [
> > ("title", "varchar", {"length": 100}),
> > ("price", "decimal", {"digits": 12, "decimals": 2}),
> > ...
> > ]
> >
> > This is not far from what "render model states" does currently except
> > that it compares much richer model descriptions that leads to no-op
> > migrations being generated each time you change a label or a
> > user-visible part of choices.
>
> Right, and one reason for generating those "no-op" migrations is that
> they aren't actually no-ops, if you value being able to write data
> migrations in Python using the ORM. They keep the historical Python
> models accurate.
>
I would argue that this is a fairly optimistic view of the current state :)
They are technically "historically accurate" but the point in history they
represent is not necessary the one you had in mind unless you only have a
single application and linear migrations (ie. no merge migrations). Our
current dependency system only allows you to express "no sooner than X" but
the graph solver can execute an arbitrary number of later migrations
between the one you depend on and the one you wrote.
Imagine you have app A and migration M1 adds field F. You then create a
migration M2 in another application B that needs to access F so you have it
depend on (A, M1). Two months later field F is removed or renamed in
migration M3. Django has two ways to linearize the graph: (A, M1), (B, M2),
(A, M3) or (A, M1), (A, M3), (B, M2). Both are valid but the latter will
result in a crash when migrating from an empty DB state. In practice we
often have to add arbitrary dependencies to later migrations to force a
Python migration to execute in the correct order.
Also I'd argue that (from my personal experience which is obviously
limited) having access to historical "choices", a form field label or the
hint are not all that useful. In fact I'd be happy with a limited migration
system that always returns bare database values without executing any of
the field code. Writing portable migrations would be a bit more work but
it's mostly a price apps would pay as projects themselves rarely need to be
portable.
Anyway, I don't want anyone to think that I complain as I don't have the
resources to write yet another migration tool and both South and Django
migrations beat writing SQL by hand.
--
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/ea0381de-d710-4467-8e4f-9d371f3154e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
