Please also review that case: https://github.com/pennersr/django-allauth/blob/master/allauth/socialaccount/models.py#L40
On Thursday, July 16, 2015 at 2:03:07 AM UTC+2, Tim Graham wrote: > > Andrew, do you think having the autodetector not "resolve" settings to > their values and instead include that as references in auto-generated > migrations is something we should try to implement? > > If so, let's suggest that solution on > https://code.djangoproject.com/ticket/24648 > > On Wednesday, July 15, 2015 at 7:58:02 PM UTC-4, Andrew Godwin wrote: >> >> Hi Marcin, >> >> Having migrations per-app is kind of a key part of the way the design >> works, but as for the rest of it, you're free to just write migrations >> yourself and ignore makemigrations - the format is intended to be >> human-writable. >> >> We also deliberately separated the schema editing backends from the >> migration code itself, so you're free to develop your own migration >> solution that overrides some of the logic of how Django works without >> having to re-implement all of the SQL abstraction, but I will tell you that >> in my experience the solution we have now is the one that works the best >> for most people (South did indeed use to have a form of semi-manual >> picking). >> >> Dependencies also make things more complex - my attempts to try and >> communicate interdependent changes to human in textual/graphic form were >> unsuccessful, hence the current method of just doing everything for you as >> best we can. >> >> As for a short-term fix, Collin's idea of importing the choices into the >> migration to stop it detecting more changes sounds like a decent temporary >> fix. >> >> Andrew >> >> On Wed, Jul 15, 2015 at 4:46 PM, Marcin Nowak <marcin....@gmail.com> >> wrote: >> >>> Thanks for clarification, Andrew. I understand it. >>> >>> The real solution (for me) is not to do anything "automagically". In my >>> "dream" I see migrations whose can be "picked" manually (or semi-manually >>> via "pickmigrations <appname>") into my project, whenever I want. No >>> autochecks, no automigration for anything, only bunch of helpers (i.e. >>> change-detector. picker). Real/valid/selected/picked migrations should be >>> "imported" as a project-wide changesets without splitting by apps (no >>> dependency problem, easier conflicts resolve), and migrations in reusable >>> apps should be provided as a resource(s) to pick/import. >>> >>> I would like to spent some time while creating stable and solid >>> migrations in my project instead of searching workarounds for runtime >>> issues. >>> But this means a big architecture change and I know that is improssible >>> to do for years... >>> >>> Thanks again. >>> Marcin >>> >>> >>> On Thursday, July 16, 2015 at 1:10:39 AM UTC+2, 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> >>>> 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. >>>>> 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/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-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/4c57141a-7ab0-40fe-ba6a-27d054b745df%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/4c57141a-7ab0-40fe-ba6a-27d054b745df%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/423e6fe6-52b7-4e90-81c4-c62d91dd1b05%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
