Re: About migrations

W dniu piątek, 7 lipca 2017 23:54:07 UTC+2 użytkownik Andrew Godwin napisał: > > There is already a run-before constraint you can add to migrations for > exactly this purpose! It's called "run_before" and is in the same format as > the dependencies IIRC. > The problem with "run before X" is that

Re: About migrations

Docs link: https://docs.djangoproject.com/en/1.11/howto/writing-migrations/#controlling-the-order-of-migrations On 7 July 2017 at 22:53, Andrew Godwin wrote: > There is already a run-before constraint you can add to migrations for > exactly this purpose! It's called "run_before" and is in the sa

Re: About migrations

There is already a run-before constraint you can add to migrations for exactly this purpose! It's called "run_before" and is in the same format as the dependencies IIRC. Andrew On Fri, Jul 7, 2017 at 6:36 PM, Carl Meyer wrote: > On 07/07/2017 05:09 AM, Patryk Zawadzki wrote: > > Right, and

Re: About migrations

On 07/07/2017 05:09 AM, Patryk Zawadzki wrote: > 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

Re: About migrations

> > > 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. > Have you tried Liquibase ever? It is very reliable, unfortunatelly it is missing automatic changeset

Re: About migrations

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 implem

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 Fie

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

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.

Re: About migrations

*About database agnostic migrations.* Liquibase is a tool which is decoupled from the app layer and gives a possibility to write agnostic changesets. To be independent you must use builtin operations and narrow used field types to "well known" subset

Re: About migrations

> > Understand when I say that what you are proposing is a very, very big > change. Django's ORM is heavily coupled to runtime information and the app > layer, and I tried for many years to decouple them and ran into all sorts > of issues as a result. Importing the fields from the source code

Re: About migrations

> > > > 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 output

Re: About migrations

> > > Some of these are problems, yes, but you have to understand they are > tradeoffs and the alternative is, in my opinion, worse. > > Yes, I understand. But maybe there is another / better alternative. Let's simplify a little and talk about a python deps first. > > I believe that there exis

Re: About migrations

ote here and in other places my thoughts about db migrations few > times, and probably Tim remembers me so well. > My opinion was not changed, but I realized that I cannot leave Django > ecosystem for a long time. > In that case I'd like to talk about migrations, their advantages and

About migrations

that case I'd like to talk about migrations, their advantages and disadvantages, and about possible solutions. Advantages: - fast (automatic) creation - database independent (model-centric) - a standard for django itself and reusable apps - possibilty to create migration

Re: Ticket #24601 - some questions about migrations

Hi, there is no need to send a mail to django-developers after leaving a comment on trac. We are notified about new comments via https://groups.google.com/forum/#!forum/django-updates already. Cheers, Florian On Monday, January 5, 2015 12:00:58 PM UTC+1, soka...@yandex.ru wrote: > > I have some

Ticket #24601 - some questions about migrations

I have some questions about model deletion mechanism in migrations. Please take a look at https://code.djangoproject.com/ticket/24061#comment:4 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe