W dniu piątek, 23 czerwca 2017 21:28:07 UTC+2 użytkownik Andrew Godwin
napisał:
>
>
>>
>> The advantages comes from db type independency, this is true, but in the
>> other side you're including the app layer dependency.
>>
>> Let's imagine that one of builtin field will change it's definition.
>> Running migrations on two different Django versions will produce two
>> different outputs.
>> My perspective is more database-like than app-like, so I'm expecting same
>> db schema as a result (for both cases).
>>
>> So the first thing that comes into my mind sounds: a complete definiton
>> should be baked in migration file. Then, when app layer changes (i.e.
>> upgrading framework or changing custom field definition), the migration
>> system should identify the change and produce new migration with baked in
>> definition. If it is possible to develop, you'll achieve less dependencies.
>> The definition (a meta-description of the field) will be baked in, instead
>> of depending on the field itself. And you'll preserve database type
>> independency.
>>
>
> How do you propose to identify "when the app layer changes"? This is a
> harder problem to solve that it first appears; the only thing you can rely
> on to compare to are the migration files themselves, so that necessarily
> means you need some description of the app layer in there.
>
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.
--
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/5efab6d9-5c76-4338-a3e3-6f55ec752c31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
