For choices, I've sometimes had my migrations import the correct choices from the live model in order to avoid needing to create extra migrations every time they change.
On Wednesday, July 15, 2015 at 7:10:39 PM UTC-4, Andrew Godwin wrote: > > Hi Marcin, > > Django persists every single field attribute change, no matter what it is > - this was a deliberate decision as we didn't want to declare certain > attributes as "not important for schema" (for example, a subclass of > ChoiceField might use an enum column type for the choices and so need that > change). > > That said, this is definitely a common problem and I'm starting to think > we should revisit it - specifically, have field classes themselves say > which attributes are not worth making changes for (perhaps combined with > greater control by fields over how their schema gets made). This isn't > currently possible though. > > Also, yes, Django doesn't see unpacked .egg files as any different than > anything else (they're just directories after all) - we have no way of > telling which apps are yours and which are external, really. This should > only happen if the external app already has a migrations directory, so the > app in question should probably try and present a consistent choices list > to the migration system in the meantime if you want to avoid this. There's > no other real fix for this right now. > > Andrew > > On Wed, Jul 15, 2015 at 5:53 PM, Marcin Nowak <marcin....@gmail.com > <javascript:>> wrote: > >> Hi Andrew, >> >> I think I've found it. This reusable app uses a kind of dynamic choices >> (based on settings or somethin' else) and Django detetcs field definition >> change (choices attr). >> >> So the question is - should Django detect change of choices attribute >> even if database schema is not really altered? >> And the original question modified - should Django generate migration >> file inside of an egg when runtime configuration or settings are changing? >> >> BR, >> Marcin >> >> >> >> On Thursday, July 16, 2015 at 12:07:52 AM UTC+2, Andrew Godwin wrote: >>> >>> Hi Marcin, >>> >>> Django will only make migrations for external apps that already have >>> "migrations" directories and have model changes - it shouldn't make new >>> migrations unless you've actually changed the models in those reuseable >>> apps. Are you sure you're not specifying the names of those apps on the >>> makemigrations command line? Are you using something like --noinput? >>> >>> Andrew >>> >>> On Wed, Jul 15, 2015 at 3:16 PM, Marcin Nowak <marcin....@gmail.com> >>> wrote: >>> >>>> Hello, >>>> >>>> I'm working on a project which is based on Django`s internal migrations. >>>> Sometimes when switching between branches (not sure for 100%), Django >>>> complains about changes in my models. >>>> >>>> When `makemigrations` command is executed Django generates migrations >>>> in external (reusable) app placed in egg. And this is *strange*, I think. >>>> I don't want to modify any external app, and I don't want to depend on >>>> temporary migrations created only on my local machine. >>>> >>>> Why Django is creating migrations for external apps, especially placed >>>> in eggs? >>>> Migrations should be handled and created only for apps within the >>>> project, and read-only for others. >>>> >>>> What do you think? >>>> How I can workaround this issue? >>>> >>>> (Django 1.7.8) >>>> >>>> >>>> Best Regards, >>>> 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-develop...@googlegroups.com. >>>> To post to this group, send email to django-d...@googlegroups.com. >>>> 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/77b46084-ffa1-43a0-ae2d-206f868cbaa5%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/77b46084-ffa1-43a0-ae2d-206f868cbaa5%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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/81e00a02-95fa-451d-aa24-1e4bd592f511%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/81e00a02-95fa-451d-aa24-1e4bd592f511%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6c396b03-53a7-4c9c-b635-9dfa46f144f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
