Re: Support for UNLOGGED tables in PostgreSQL

[Christophe Pettus]

On Jul 15, 2015, at 8:35 PM, Curtis Maloney  wrote:

> On 16 July 2015 at 05:01, Shai Berger  wrote:
>> This is a shot in the dark: Could it be that rolling back transactions
>> involving unlogged tables is harder? The idea does make sense, and running 
>> the
>> test suite does an extremely untypical amount of rollbacks.
> 
> I thought at some point I read that unlogged tables didn't support
> transactions... however, the docs don't agree.

Transactions behave the same in PostgreSQL for both logged and unlogged tables 
(except for, of course, the lack of a commit / rollback entry in the WAL), and 
there's no appreciable performance benefit on COMMIT and ROLLBACK time for 
logged vs unlogged.

My guess is that the Django tests are not generating enough data to make the 
WAL activity be a significant time sink.

By the way, I would strongly advise *against* *ever* even mentioning fsync = 
off anywhere in the Django documentation; that is such a horribly bad idea in 
99.95% of real-life situations that steering people towards it as a "go faster" 
button is very unwise.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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/9B2A4A22-09FF-4634-AF4A-536C022FC57E%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for UNLOGGED tables in PostgreSQL

[Curtis Maloney]

On 16 July 2015 at 05:01, Shai Berger  wrote:
> This is a shot in the dark: Could it be that rolling back transactions
> involving unlogged tables is harder? The idea does make sense, and running the
> test suite does an extremely untypical amount of rollbacks.

I thought at some point I read that unlogged tables didn't support
transactions... however, the docs don't agree.

I was also considering going to the PG people and asking if the
UNLOGGED docs needed review... there could be all manner of reasons
why, on modern hardware, going via the WAL is as fast now...

--
C

-- 
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/CAG_XiSCcZ%3Df-919dSdOif0ZVMT6fma5yE3xy20%2Bw7E04y2E3kQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django is making migrations for external apps?

[Andrew Godwin]

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 work towards something where fields could just say
"choices/label/etc. don't matter" and ship default ignores with all the
core fields.

Andrew

On Wed, Jul 15, 2015 at 5:03 PM, 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 
>> 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 ") 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 
 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:
>>

Re: Why Django is making migrations for external apps?

[Collin Anderson]

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 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  
>>> 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 ") 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  
> 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 config

Re: Why Django is making migrations for external apps?

[Marcin Nowak]

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  
>> 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 ") 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  
 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 i

Re: Why Django is making migrations for external apps?

[Tim Graham]

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  > 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 ") 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  
>>> 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  
> wrote:
>
>> Hello,
>>
>> I'm working on a 

Re: Why Django is making migrations for external apps?

[Andrew Godwin]

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 
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 ") 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 
>> 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 
 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 externa

Re: Why Django is making migrations for external apps?

[Marcin Nowak]

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 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  > 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  
>>> 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
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  -- 
>> You received this message because you are subscribed to the 

Re: Why Django is making migrations for external apps?

[Collin Anderson]

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  > 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  
>>> 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
  
 
 .
 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
>>  
>> 
>> .
>>
>> For more options, visit ht

Re: Why Django is making migrations for external apps?

[Andrew Godwin]

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 
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 
>> 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
>>> 
>>> .
>>> 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/81e00a02-95fa-451d-aa24-1e4bd592f511%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 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://group

Re: Why Django is making migrations for external apps?

[Marcin Nowak]

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  > 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
>>  
>> 
>> .
>> 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/81e00a02-95fa-451d-aa24-1e4bd592f511%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django is making migrations for external apps?

[Andrew Godwin]

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 
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-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/77b46084-ffa1-43a0-ae2d-206f868cbaa5%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 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/CAFwN1upjy7GrrADEgvkzneBo9XZaLTS%2B%2BXLXpjrQnR7%3D3isYCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Why Django is making migrations for external apps?

[Marcin Nowak]

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-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/77b46084-ffa1-43a0-ae2d-206f868cbaa5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for UNLOGGED tables in PostgreSQL

[Shai Berger]

This is a shot in the dark: Could it be that rolling back transactions 
involving unlogged tables is harder? The idea does make sense, and running the 
test suite does an extremely untypical amount of rollbacks.

On Wednesday 15 July 2015 16:19:47 Federico Capoano wrote:
> That's quite baffling.
> 
> On Tuesday, July 14, 2015 at 7:03:03 PM UTC+2, Tim Graham wrote:
> > I see a thirty second increase in the test suite (from 7.5 minutes to 8
> > minutes) on my local machine with:
> > 
> > sql_create_table = "CREATE UNLOGGED TABLE %(table)s (%(definition)s)"

Re: Renaming the postgresql_psycopg2 backend

[Collin Anderson]

We definitely should make sure postgresql_psycopg2 still works as expected. 
As a data point, Heroku uses "postgres" instead of "postgresql" in their 
DATABASE_URL scheme. Maybe we could support all three? :)

On Wednesday, July 15, 2015 at 9:17:30 AM UTC-4, Baptiste Mispelon wrote:
>
> Hi everyone, 
>
> After starting a new project recently and failing three times to type 
> the name of the postgres backend correctly, I was wondering if there's 
> really any value in keeping around this strange name. 
>
>  From what I understand, it's a historical artifact from a time when 
> there was more than one postgres backend. 
>
>
> Could we at least make it an alias of a more simply named "postgresql" 
> backend? 
>
>
> Thanks, 
> Baptiste 
>

-- 
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/3ab4f912-fc25-4859-bd8d-5651e2c68e93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Renaming the postgresql_psycopg2 backend

[Andriy Sokolovskiy]

Good proposal.
If there will be release of psycopg3, which will work without serious
changes to django codebase, this old name can bring more confusion, so need
to deprecate this.

On 7/15/15 15:17, Baptiste Mispelon wrote:
> Hi everyone,
> 
> After starting a new project recently and failing three times to type
> the name of the postgres backend correctly, I was wondering if there's
> really any value in keeping around this strange name.
> 
> From what I understand, it's a historical artifact from a time when
> there was more than one postgres backend.
> 
> 
> Could we at least make it an alias of a more simply named "postgresql"
> backend?
> 
> 
> Thanks,
> Baptiste
> 

-- 
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/55A65EEB.9060707%40asokolovskiy.com.
For more options, visit https://groups.google.com/d/optout.

Re: Renaming the postgresql_psycopg2 backend

[Federico Capoano]

I would definitely second this.


On Wednesday, July 15, 2015 at 3:17:30 PM UTC+2, Baptiste Mispelon wrote:
>
> Hi everyone, 
>
> After starting a new project recently and failing three times to type 
> the name of the postgres backend correctly, I was wondering if there's 
> really any value in keeping around this strange name. 
>
>  From what I understand, it's a historical artifact from a time when 
> there was more than one postgres backend. 
>
>
> Could we at least make it an alias of a more simply named "postgresql" 
> backend? 
>
>
> Thanks, 
> Baptiste 
>

-- 
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/042eb416-701c-46a9-b5e7-845d270f8ce7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for UNLOGGED tables in PostgreSQL

[Federico Capoano]

That's quite baffling.


On Tuesday, July 14, 2015 at 7:03:03 PM UTC+2, Tim Graham wrote:
>
> I see a thirty second increase in the test suite (from 7.5 minutes to 8 
> minutes) on my local machine with:
>
> sql_create_table = "CREATE UNLOGGED TABLE %(table)s (%(definition)s)"
>

-- 
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/239f0228-5cec-4957-8d3a-146fed22377b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Renaming the postgresql_psycopg2 backend

[Baptiste Mispelon]

Hi everyone,

After starting a new project recently and failing three times to type 
the name of the postgres backend correctly, I was wondering if there's 
really any value in keeping around this strange name.


From what I understand, it's a historical artifact from a time when 
there was more than one postgres backend.



Could we at least make it an alias of a more simply named "postgresql" 
backend?



Thanks,
Baptiste

--
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/55A65D4F.1020704%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

ForeignObject defaults to virtual_only=False?

[Anssi Kääriäinen]

If I recall correctly the real significance of virtual_only is that fields
added with this flag are copied to child models. Generic relations need
this as they need to know the model they are used on. Normal fields are not
copied, instead they are fetched directly from the parent model when _meta
is queried.

So, it might be possible to rename virtual_only to something like
copy_to_childs, and then virtuality of a field would be determined only on
it having a column.

Even better would be if fields had a get_migration_operations(from_state,
to_state) method. Then migrations wouldn't have to know anything else than
to call that method. This would also be very useful method for 3rd party
fields.

 - Anssi

On Wednesday, July 15, 2015, Tim Graham > wrote:

> ForeignObject defaults to virtual_only=False [1]. This seems
> counterintuitive as my understanding is that ForeignObject fields are
> virtual (i.e. they don't directly map to a database column).
>
> I am testing Andrew's patch to allow disabling migrations in tests [2] and
> ran into a problem in Django's test suite because of this. For models with
> ForeignObject fields [3], these fields appear in model._meta.local_fields
> and so are added to migrations which raises an exception because
> field.column is None. I tried changing ForeignObject to default to
> virtual_only=True (and kept ForeignKey virtual_only=False), but there were
> non-trivial test failures, so I wanted to check my understanding before
> going down a wormhole.
>
> My experimental branch is https://github.com/django/django/pull/4997
>
> [1]
> https://github.com/django/django/blob/b356dc4e07915521db1e768d6357e3d982877a6e/django/db/models/fields/related.py#L1830-L1832
> [2] https://github.com/django/django/pull/4986
> [3]
> https://github.com/django/django/blob/b356dc4e07915521db1e768d6357e3d982877a6e/tests/foreign_object/models.py#L60-L68
>
>  --
> 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/e88f0124-ba52-4b21-8825-ae73824f1040%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 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/CALMtK1HYiBjRHw6%2Br3ibmBNQH%3DGx3wp48LhUA5akt1msdP2bhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.