makemigrations shouldn't automatically add model managers to migrations 
files. Did you opt them in with `use_in_migrations = True`? If so, I 
believe you have to drop compatibility with Django 1.7 (i.e. are you 
limited to the migrations feature set of the lowest version of Django you 
wish to support).

https://docs.djangoproject.com/en/1.8/topics/migrations/#model-managers

On Wednesday, April 22, 2015 at 8:41:34 AM UTC-4, Patrick Craston wrote:
>
> Hi Tim
>
> If I create a migration on the lowest Django version I wish to support 
> (say 1.7), it will not add the AlterModelManager operation to the 
> migration. If someone installs the app on Django 1.8, the migration will 
> run fine. 
>
> However, every time the user runs "migrate" after that it will complain 
> about the models having changes that are not reflected in a migration and 
> ask the user to run "makemigrations" which doesn't seem right?
>
> On Wednesday, 22 April 2015 13:13:40 UTC+1, Tim Graham wrote:
>>
>> The recommended way is to run makemigrations with the lowest version of 
>> Django you wish to support. As this recommendation hasn't been tested, let 
>> us know if you encounter any problems with it. A potential problem that 
>> comes to mind is if you have an EmailField which had its default max_length 
>> increased to 254 characters in 1.8. If you run makemigrations using 1.7, 
>> you won't get a migration to increase the length of that column. The best 
>> solution is probably to add an explicit max_length=254 to such fields.
>>
>>
>> https://docs.djangoproject.com/en/1.8/topics/migrations/#supporting-multiple-django-versions
>>
>> On Wednesday, April 22, 2015 at 7:32:48 AM UTC-4, Patrick Craston wrote:
>>>
>>> Hi all
>>>
>>> I'm creating a migration for a 3rd party app that needs to work with 
>>> current and previous Django versions. In Django 1.8 "makemigrations" adds a 
>>> "AlterModelManager" operation which only works with Django 1.8 and later 
>>> since AlterModelManager didn't exist before. It will also do an AlterField 
>>> to convert the IPAddressField to GenericIPAddressField.
>>>
>>> I currently have this: 
>>> https://gist.github.com/anonymous/e4d7f4f6dfd48988640d
>>>
>>> Basically I append to migrations operations if django.VERSION >= (1,8). 
>>> But as was mentioned in #django IRC, if the user applies the app's 
>>> migration in Django 1.7 those migrations don't get applied. If the user 
>>> then upgrades to Django 1.8, the user would miss those migrations?
>>>
>>> Is there a recommended way of altering migration operations depending on 
>>> django.VERSION? If yes, do you think it might be worth adding a note in 
>>> the documentation?
>>>
>>> Thank you!
>>> Patrick
>>>
>>

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b8607879-3c43-4a94-a18c-6828b36dc882%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to