Re: About migrations
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.
Of course, we do pay a cost in complexity for the "historical ORM"
feature, and it's reasonable to prefer a tradeoff that doesn't pay that
cost and requires all data migrations to be written in SQL. As Andrew
mentioned, there's nothing to prevent anyone from writing an alternative
migrations frontend that takes this approach. It should be able to reuse
the schema editor backend, which does the heavy lifting of cross-db
schema alteration.
It's worth remembering, though, that five or six years ago we _had_ a
range of different migrations solutions that chose different tradeoffs,
and South was the clear winner in user uptake. It's not due to arbitrary
whim that the Django migrations system is based on South and preserves
its popular features, like the historical ORM.
Carl
--
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/43abcfed-edaa-6f05-04cc-f30a9b0e59e6%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
Fwd: Us congress hearing of maan alsaan Money laundry قضية الكونغجرس لغسيل الأموال للمليادير معن الصانع
YouTube videos of U.S. Congress money laundering hearing of Saudi Billionaire " Maan Al sanea" with *bank of America* and The owner of Saad Hospital and Schools in the Eastern Province in *Saudi Arabia* and the Chairman of the Board of Directors of Awal Bank in *Bahrain* With Arabic Subtitles *موقع اليوتيوب الذي عرض جلسة استماع الكونجرس الأمريكي * * لمتابعة نشاطات غسل الأموال ونشاطات* *السعودي معن عبدالواحد الصانع* *مالك مستشفى وشركة سعد ومدارس سعد بالمنطقة الشرقية بالسعودية ورئيس مجلس ادارة بنك اوال البحريني* *مترجم باللغة العربية* http://www.youtube.com/watch?v=mIBNnQvhU8s -- Message URL: https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id Unsubscribe: send a message to django-cms-developers+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "django CMS developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-developers+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/CAFxgSVKObnKYrrhNjS9th9nmHbrE4rmzi1GXg%3DmSZDesnByWdA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: About migrations
> > Have each Field class deconstruct to a field name and params [...] Thanks, @patrys. A field deconstruction is a key to achieve what I tried to describe earlier. We can discuss the details about implementation, but this is not important now. 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/62f0734e-5519-4935-a6fe-aace4b31aa76%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: About migrations
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.
