On Mon, Jul 20, 2015 at 11:56:40AM -0600, Carl Meyer wrote:
On 07/20/2015 11:47 AM, Shai Berger wrote:
On Monday 20 July 2015 18:47:07 Carl Meyer wrote:
Personally I don't really see much use case for this feature
except as a workaround for reusable apps that generate spurious new
migrations
On 07/20/2015 11:47 AM, Shai Berger wrote:
> On Monday 20 July 2015 18:47:07 Carl Meyer wrote:
>>>
Personally I don't really see much use case for this feature
except as a workaround for reusable apps that generate spurious new
migrations based on settings changes
>>>
>>> I've also s
On Monday 20 July 2015 18:47:07 Carl Meyer wrote:
> >
> >> Personally I don't really see much use case for this feature
> >> except as a workaround for reusable apps that generate spurious new
> >> migrations based on settings changes
> >
> > I've also seen it with apps that use "EmailField" with
On 07/19/2015 06:14 AM, Anssi Kääriäinen wrote:
> To me it seems the choice of doing migrations for app/model should be
> done by the author of the app.
>
> How about model/app level setting migrations_mode, where the choices are
> auto, manual and never. Auto is the defaul and behaves like curren
Hi Shai,
On 07/19/2015 01:52 AM, Shai Berger wrote:
[snip]
>> It seems like what Marcin wants is more of a "don't ever create new
>> migrations for this app, but go ahead and use its existing ones
>> normally" flag (thus something that affects only `makemigrations`, not
>> `migrate`).
>
> That's
To me it seems the choice of doing migrations for app/model should be done
by the author of the app.
How about model/app level setting migrations_mode, where the choices are
auto, manual and never. Auto is the defaul and behaves like current Django.
Manual means that you'll have to mention the app
On Friday 17 July 2015 19:48:30 Carl Meyer wrote:
> On 07/17/2015 10:38 AM, Marcin Nowak wrote:
> > Sounds enough good. One important thing for me is that I have many of
> > external apps and few in project managed by me. Reconfiguring most of
> > apps just to tell Django "leave them alone" sounds
On 07/17/2015 10:38 AM, Marcin Nowak wrote:
> Sounds enough good. One important thing for me is that I have many of
> external apps and few in project managed by me. Reconfiguring most of
> apps just to tell Django "leave them alone" sounds like an overhead.
> That's why I would like to tell Django
Sounds enough good. One important thing for me is that I have many of
external apps and few in project managed by me. Reconfiguring most of apps
just to tell Django "leave them alone" sounds like an overhead. That's why
I would like to tell Django "here are my apps, manage them please".
BR
Marcin
On Friday, July 17, 2015 at 6:31:20 PM UTC+2, Andrew Godwin wrote:
>
>
>
> On Fri, Jul 17, 2015 at 11:19 AM, James Bennett > wrote:
>
>> One option for declaring an app "unmanaged" could be via AppConfig.
>> That's fairly clean, mirrors the way you can already set a model as
>> unmanaged in it
+1!
Loïc
> On Jul 17, 2015, at 23:30, Andrew Godwin wrote:
>
>
>
> On Fri, Jul 17, 2015 at 11:19 AM, James Bennett wrote:
> One option for declaring an app "unmanaged" could be via AppConfig. That's
> fairly clean, mirrors the way you can already set a model as unmanaged in its
> Meta decl
On Fri, Jul 17, 2015 at 11:19 AM, James Bennett
wrote:
> One option for declaring an app "unmanaged" could be via AppConfig. That's
> fairly clean, mirrors the way you can already set a model as unmanaged in
> its Meta declaration, and allows for the end user of the app to override by
> supplying
One option for declaring an app "unmanaged" could be via AppConfig. That's
fairly clean, mirrors the way you can already set a model as unmanaged in
its Meta declaration, and allows for the end user of the app to override by
supplying an AppConfig which will generate migrations (should they, for
so
If we're going to introduce another setting, which I'm not super-keen on,
then let's made it exclusionary, something like MIGRATION_UNMANAGED_APPS.
Or, we could do something with the existing MIGRATION_MODULES setting, but
migrate needs that too so it might be confusing things.
Andrew
On Fri, Ju
I would like to set something like MIGRATION_MANAGED_APPS = (...) in my
project`s settings.
Every not listed app should not be inspected and should be excluded when
calling `makemigrations` command.
Setting MIGRATION_MANAGED_APPS to None (default) should enable backward
compatibility.
On 17 July
On Thursday 16 July 2015 02:10:12 Andrew Godwin wrote:
>
> 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.
In my experience, most project
Hi Markus,
My proposed solution simply offers a way to opt-in the attribute exclusion
behavior, I didn't mean to solve the whole data migration access to a
particular state issue.
While I see merit in your proposal I cannot understand how it's not also
encouraging people to use it for the wron
Hi all,
While your proposal could solve the repeated creation of migrations due to
dynamic choices, Simon, I don't see how it would solve or prevent the issue
Carl mentioned earlier. Data migrations may need to have the exact choices at
that particular state. Importing the current choices may f
Hi everyone,
Here's just an idea from the top of my head.
What if we exposed a `django.db.migrations.Reference`
that would be a deconstructible proxy to a top level module object.
It would be initialized with a module name string and the referenced
object name as a second argument. We could docum
Hi Andrew and Marcin,
On 07/15/2015 05:10 PM, Andrew Godwin wrote:
> 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
> ChoiceFiel
The problem is that migrations are designed to work even when you've
changed the original models, so we can't have the design include something
where we reference the original models file (if I remove that field, all
previous migrations that refer to it start having ImportErrors).
I'd rather we wo
Ahh, yes, that's a good example of what I was thinking of:
https://github.com/pennersr/django-allauth/blob/fb2851fe333f303faab28e9633b6cf1b0ddbbe98/allauth/socialaccount/migrations/0001_initial.py#L39
On Wednesday, July 15, 2015 at 8:17:33 PM UTC-4, Marcin Nowak wrote:
>
> Please also review that
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 includ
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
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
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 ") into my project, whenever I want. No
autochecks, no automigration for anyt
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 at
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
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 altere
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
ma
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
31 matches
Mail list logo
