Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2016-04-18 Thread marcin . j . nowak
On Friday, February 27, 2015 at 11:22:13 PM UTC+1, Gergely Polonkai wrote: > > Hello, > > another solution may be to patch your models in the migration module or > class > The best solution is not to use Django built-in migrations. Of course you can create them very quickly (via automatic

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-27 Thread Gergely Polonkai
Hello, another solution may be to patch your models in the migration module or class, like: import myapp.models myapp.models.valid_identifier = something_acceptable() Although it seems a bit ugly, I just tested it, and it works. This way valid_identifier will live during the migration only.

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-27 Thread Luis Masuelli
Thanks :D Did not think about squashing migrations as solution for this problem! But it does the job. OTOH the fact about historical models has nothing to do with my problem (since it is not related at all with instancing a model, but just about the definition and not getting a NameError). --

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-26 Thread Carsten Fuchs
Hi all, Am 26.02.2015 um 13:54 schrieb Tim Graham: Yes, it's expected behavior. Please see the documentation on the topic: https://docs.djangoproject.com/en/stable/topics/migrations/#historical-models I have not yet tried this, but won't squashing migrations as a side effect also get us rid

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-26 Thread Carl Meyer
On 02/26/2015 08:41 AM, Carsten Fuchs wrote: > Hi all, > > Am 26.02.2015 um 13:54 schrieb Tim Graham: >> Yes, it's expected behavior. Please see the documentation on the topic: >> https://docs.djangoproject.com/en/stable/topics/migrations/#historical-models >> > > I have not yet tried this, but

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-26 Thread Tim Graham
Yes, it's expected behavior. Please see the documentation on the topic: https://docs.djangoproject.com/en/stable/topics/migrations/#historical-models On Wednesday, February 25, 2015 at 3:25:19 PM UTC-5, Luis Masuelli wrote: > > I have an issue with migrations. > > Suppose I declare (in my

Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-25 Thread Luis Masuelli
I have an issue with migrations. Suppose I declare (in my application, with name myapp) a field with a validators= declared. In such value (which is an iterable), I declare a function: class MyModel(models.Model): """ This one is identifiable. """ identifier =