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

[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 "makemigrations"), but this is 
probably just the only advantage. Everyting else is something what I'm 
calling "built-in hell". 

Try to use external solutions like Liquibase. But remember - you'll need to 
track builtin schema changes (as a part of "builtin-hell") and converting 
3rd app migrations. 
Also guys from Django Team removed very useful command - `sql`, which was a 
base tool for speeding up of Liquibase changesets creation. But until you 
know what you're doing, you can write every change manually. As a result 
you're getting rock-solid db schema management without python imports 
problem, without historical problems nor models, without strange squashing 
ideas, refactoring horror, and so on... 

Kind Regards,
Marcin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4cc59dcd-782c-46f3-afe2-3c16f61d57f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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.

Best,
Gergely
On 27 Feb 2015 21:17, "Luis Masuelli"  wrote:

> 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).
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/15bb8a96-18a5-432c-afeb-7a3299ca7a4d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACczBUJz9A%2ByKxTkP-prtfXihoSudM6V0HLD_mXUZTu2yQqjkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[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).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/15bb8a96-18a5-432c-afeb-7a3299ca7a4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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 of dependencies of historical models?


Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54EF3EAE.3040004%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

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

[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 won't squashing migrations as a side
> effect also get us rid of dependencies of historical models?

Yes, squashmigrations is the right way to deal with this problem.

If you have RunPython/RunSQL migrations that can also safely go away,
you'll need to manually excise them before squashing in order to get a
complete squash, since they are opaque to squashmigrations and won't be
optimized across. See https://code.djangoproject.com/ticket/24109

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54EF40B4.6020305%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

[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 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 = models.CharField(max_length=10, unique=True, validators=[
> valid_identifier])
>
> Assume I created the migration with makemigrations:
>
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import models, migrations
> from django.conf import settings
> import django.core.validators
> import micnt.models
>
>
> class Migration(migrations.Migration):
>
> dependencies = [
> ...
> ]
>
> operations = [
> migrations.CreateModel(
> name='MyModel',
> fields=[
> ('identifier', models.CharField(max_length=10, unique=True
> , validators=[myapp.models.valid_identifier])),
> ],
> options={
> },
> bases=(models.Model,),
> ),
> ]
>
> Assume valid_identifier is any external callable which will take one 
> positional argument, and eventually raise ValidationError under certain 
> conditions.
>
> Now the requirements vary: The identifier may be national or foreign, so 
> the country is required as an additional field, and also a discriminator 
> field. Additionally, the validation I must perform is cross-field, so 
> instead of using something in validators, I define a clean() method, and 
> make the combination of country/identifier unique, instead of just the 
> identifier unique:
>
> class MyModel(models.Model):
> """
> This one is identifiable.
> """
>
> identifier_type = models.CharField(max_length=10, 
> choices=(('passport', _(u'Passport')), ('national', _(u'National'))), 
> null=False)
> identifier = models.CharField(max_length=10)
> country = models.ForeignKey(Country, null=False)  # assume Country 
> model exists
>
> class Meta:
> unique_together = (('identifier', 'country'),)
>
> def clean(self):
> raise ValidationError('Implement this!')
> 
>
> And then, I don't need anymore the valid_identifier function, since my 
> code does not use it anymore. So I delete it.
>
> Now I will create the migration with makemigrations as usual. What will 
> happen?
>
> a. The command will succeed.
> b. The command will explode (i. e. a normal Python exception).
> c. The command will create an inconsistent migration, without exploding.
> d. Jesus will come again.
> e. The command will get into a kind of endless loop.
>
> If you guesses "b", you were right. Django will report an error, since 
> myapp.models.valid_identifier does not exist anymore (AttributeError).
>
> So, once I set a value for validators= parameter and create a migration, I 
> am forced to keep such reference valid for the rest of my life (e.g. by 
> having valid_identifier=None, if I don't need the function anymore), or 
> else the migrations will not work again since they will be traversed, 
> imported, and will get such AttributeError.
>
> Is this an expected, normal, behavior?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/aa3cc60a-50e2-4be6-a430-0ae1d351e2b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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 = models.CharField(max_length=10, unique=True, validators=[
valid_identifier])

Assume I created the migration with makemigrations:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations
from django.conf import settings
import django.core.validators
import micnt.models


class Migration(migrations.Migration):

dependencies = [
...
]

operations = [
migrations.CreateModel(
name='MyModel',
fields=[
('identifier', models.CharField(max_length=10, unique=True, 
validators=[myapp.models.valid_identifier])),
],
options={
},
bases=(models.Model,),
),
]

Assume valid_identifier is any external callable which will take one 
positional argument, and eventually raise ValidationError under certain 
conditions.

Now the requirements vary: The identifier may be national or foreign, so 
the country is required as an additional field, and also a discriminator 
field. Additionally, the validation I must perform is cross-field, so 
instead of using something in validators, I define a clean() method, and 
make the combination of country/identifier unique, instead of just the 
identifier unique:

class MyModel(models.Model):
"""
This one is identifiable.
"""

identifier_type = models.CharField(max_length=10, choices=(('passport', 
_(u'Passport')), ('national', _(u'National'))), null=False)
identifier = models.CharField(max_length=10)
country = models.ForeignKey(Country, null=False)  # assume Country 
model exists

class Meta:
unique_together = (('identifier', 'country'),)

def clean(self):
raise ValidationError('Implement this!')


And then, I don't need anymore the valid_identifier function, since my code 
does not use it anymore. So I delete it.

Now I will create the migration with makemigrations as usual. What will 
happen?

a. The command will succeed.
b. The command will explode (i. e. a normal Python exception).
c. The command will create an inconsistent migration, without exploding.
d. Jesus will come again.
e. The command will get into a kind of endless loop.

If you guesses "b", you were right. Django will report an error, since 
myapp.models.valid_identifier does not exist anymore (AttributeError).

So, once I set a value for validators= parameter and create a migration, I 
am forced to keep such reference valid for the rest of my life (e.g. by 
having valid_identifier=None, if I don't need the function anymore), or 
else the migrations will not work again since they will be traversed, 
imported, and will get such AttributeError.

Is this an expected, normal, behavior?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0f186fe2-e37a-41ef-882f-9d509dd6c5cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.