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
i
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 t
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 t
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 ke
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
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
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.
>
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
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
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 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
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
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
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
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
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
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
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
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
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 untyp
20 matches
Mail list logo
