Re: [Django] #31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup instead of overridden lookup

[Django]

#31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup 
instead of
overridden lookup
-+-
 Reporter:  sage |Owner:  sage
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sage):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13238 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0544f40a5d576bb79b69776736e413cd%40djangoproject.com.

Re: [Django] #31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup instead of overridden lookup

[Django]

#31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup 
instead of
overridden lookup
-+-
 Reporter:  sage |Owner:  sage
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sage):

 * owner:  nobody => sage
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6e582342ab2b1d98c1677be90d8e2431%40djangoproject.com.

Re: [Django] #31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup instead of overridden lookup

[Django]

#31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup 
instead of
overridden lookup
-+-
 Reporter:  sage |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by sage:

Old description:

> The previous implementation of `django.contrib.postgres.fields.JSONField`
> uses the overridden `contains` lookup that is JSON-based and not the
> builtin one that is pattern-based.
>
> Using the example model in the 3.1 release notes,
>
> {{{
> class ContactInfo(models.Model):
> data = models.JSONField()
>
> obj = ContactInfo.objects.create(data={
> 'name': 'John',
> 'cities': ['London', 'Cambridge'],
> 'pets': {'dogs': ['Rufus', 'Meg']},
> })
> ContactInfo.objects.filter(
> data__cities__contains='Cambridge',
> )
> }}}
>
> The query returns a queryset with `obj` in it, which is expected.
>
> However, the following query:
>
> {{{
> ContactInfo.objects.filter(
> data__cities__contains='bridge',
> )
> }}}
>
> Also returns a queryset with `obj` in it. Using the previous
> implementation, `obj` doesn't match the query because `contains` uses
> JSON-based containment checking. That is, it checks whether the array in
> `data__cities` contains an element that's exactly `"bridge"`.

New description:

 The previous implementation of `django.contrib.postgres.fields.JSONField`,
 when chained with a `KeyTransform` and a `contains` lookup, uses the
 overridden `contains` lookup that is JSON-based and not the builtin one
 that is pattern-based.

 Using the example model in the 3.1 release notes,

 {{{
 class ContactInfo(models.Model):
 data = models.JSONField()

 obj = ContactInfo.objects.create(data={
 'name': 'John',
 'cities': ['London', 'Cambridge'],
 'pets': {'dogs': ['Rufus', 'Meg']},
 })
 ContactInfo.objects.filter(
 data__cities__contains='Cambridge',
 )
 }}}

 The query returns a queryset with `obj` in it, which is expected.

 However, the following query:

 {{{
 ContactInfo.objects.filter(
 data__cities__contains='bridge',
 )
 }}}

 Also returns a queryset with `obj` in it. Using the previous
 implementation, `obj` doesn't match the query because `contains` uses
 JSON-based containment checking. That is, it checks whether the array in
 `data__cities` contains an element that's exactly `"bridge"`.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5c56a11524f89d5c85afd805f486c85d%40djangoproject.com.

[Django] #31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup instead of overridden lookup

[Django]

#31829: Chaining KeyTransform with 'contains' lookup uses builtin lookup 
instead of
overridden lookup
-+-
   Reporter:  sage   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The previous implementation of `django.contrib.postgres.fields.JSONField`
 uses the overridden `contains` lookup that is JSON-based and not the
 builtin one that is pattern-based.

 Using the example model in the 3.1 release notes,

 {{{
 class ContactInfo(models.Model):
 data = models.JSONField()

 obj = ContactInfo.objects.create(data={
 'name': 'John',
 'cities': ['London', 'Cambridge'],
 'pets': {'dogs': ['Rufus', 'Meg']},
 })
 ContactInfo.objects.filter(
 data__cities__contains='Cambridge',
 )
 }}}

 The query returns a queryset with `obj` in it, which is expected.

 However, the following query:

 {{{
 ContactInfo.objects.filter(
 data__cities__contains='bridge',
 )
 }}}

 Also returns a queryset with `obj` in it. Using the previous
 implementation, `obj` doesn't match the query because `contains` uses
 JSON-based containment checking. That is, it checks whether the array in
 `data__cities` contains an element that's exactly `"bridge"`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.438ac08e0d696048638681207036dd14%40djangoproject.com.

Re: [Django] #31811: Add optional timing outputs to the test runner

[Django]

#31811: Add optional timing outputs to the test runner
-+-
 Reporter:  Ahmad A. Hussein |Owner:  Ahmad A.
 |  Hussein
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  timing, test runner  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ahmad A. Hussein):

 * needs_better_patch:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.89d9434b9633bdb185fbc9ca464337f0%40djangoproject.com.

Re: [Django] #31335: [mysql] Renaming a foreign key field that's also included in an index fails with "Cannot drop index 'foo_idx': needed in a foreign key constraint"

[Django]

#31335: [mysql] Renaming a foreign key field that's also included in an index 
fails
with "Cannot drop index 'foo_idx': needed in a foreign key constraint"
--+
 Reporter:  Stephen Finucane  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  3.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Perry Harrington):

 * cc: Perry Harrington (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.368d8dfbec048c645689c08fe4a467f4%40djangoproject.com.

Re: [Django] #31335: [mysql] Renaming a foreign key field that's also included in an index fails with "Cannot drop index 'foo_idx': needed in a foreign key constraint"

[Django]

#31335: [mysql] Renaming a foreign key field that's also included in an index 
fails
with "Cannot drop index 'foo_idx': needed in a foreign key constraint"
--+
 Reporter:  Stephen Finucane  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  3.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Perry Harrington):

 There is a variation of this bug that goes to the core of the problem.

 You have a model like this:

 class Insect
 species = fk to model Species
 has_wings = Boolean

 You create the initial migration and it generates roughly this:

 Table Insect
 id
 species_id
 has_wings bool
 PRIMARY_KEY(id)
 KEY someconstraint (species_id)
 CONSTRAINT someconstraint FK (species_id) REFERENCES species (id)

 The CONSTRAINT keyword in the initial sql migration script will
 automatically create an index named the same as the related name.

 Django doesn't know about this magical key, since it didn't create it.

 Next you add a new index with the following:

 indexes = [
 ...Index(fields=['species_id','id','has_wings'])
 ]

 The migration then creates something like this:

 ALTER TABLE ADD INDEX someindex (species_id,id,has_wings)

 Then MySQL silently deletes the supporting FK constraint index that it
 created, replacing that single column index with the compound index you
 just specified.

 The *crucial* factor in MySQL's decision to drop the automagic index is
 whether the FK is the first column in the index.

 If the FK is the first column of the secondary index, MySQL drops it
 because the automagic index is a duplicate.

 Next, if you instead decide to change the index to:

 indexes = [
 ...Index(fields=['id','has_wings'])
 ]

 When you run the migration, Django generates a DROP index for the
 secondary index, but because it's used as the FK constrain index, MySQL
 refuses.

 The same would happen if you changed the order of the columns in the index
 (because column order is critical to access path):

 indexes = [
 ...Index(fields=['id','species_id','has_wings'])
 ]

 This may look like the same index, but it's not, and Django will drop the
 old one and create the new one in the new order, generating another FK
 error.

 There are a few problems here:

 - Django doesn't know about the shadow index and therefore its dependency
 calculation does not take into account MySQL automagically creating and
 dropping the FK dependent index
 - Django DROPs indexes before creating new indexes

 First, Django should create indexes before dropping indexes, this will
 automatically resolve the dependency issue if the new index has the FK as
 the first column of the index.

 Second, if Django is creating a migration for a table where the FK was the
 first column in a previously seen index, but that index is gone in the new
 migration and there is no new index with the FK as the first column, then
 it should automatically generate an FK constraint index with the name of
 the FK constraint.

 Put another way:
 if old index set contained FK as first column, but new index set does not
 have any index with FK as first column, generate a new KEY with just FK as
 column.
 Then you can drop old index and add new indexes.

 But, belt and suspenders, you should add indexes before dropping indexes,
 this can help cover corner cases.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.e654353f2c51a03da8717e14f3f9b6e3%40djangoproject.com.

[Django] #31828: no such table: main.auth_user__old error in Admin

[Django]

#31828: no such table: main.auth_user__old error in Admin
-+
   Reporter:  BillKennish|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I am going through the DjangoProjects tutorial that creates a Polls app. I
 have installed everything and created the app. I can see the table entries
 in the Polls tables. I am at the point where I go into the Admin page. I
 created a superuser and logged into the Admin. The page comes up fine. My
 Questions table is properly listed. When I look into the table it shows
 the one practice question just fine. When I click on Edit it brings up the
 record with the proper question. But when I try to save a change to the
 data I get the following error message: "no such table:
 main.auth_user__old". (plus a lot more). I am at a loss as to where I went
 astray. Thoughts?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.0a1ed40639a3d232fb8add5ebe487c3b%40djangoproject.com.

Re: [Django] #31826: AlterField with only db_column changed should be a noop

[Django]

#31826: AlterField with only db_column changed should be a noop
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Iuri de Silvio):

 * version:  3.0 => master


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.c392954aad76d08c32837e00bfb76934%40djangoproject.com.

Re: [Django] #31825: RenameField with db_column defined drop and recreate the same constrainsts on Postgres

[Django]

#31825: RenameField with db_column defined drop and recreate the same 
constrainsts
on Postgres
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Iuri de Silvio):

 * version:  3.0 => master


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.afe6ae5060cc80b54157d57818edde44%40djangoproject.com.

Re: [Django] #31262: Support dictionaries in Field.choices for named groups.

[Django]

#31262: Support dictionaries in Field.choices for named groups.
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom Forbes):

 * needs_docs:  1 => 0


Comment:

 Thanks for the review! I've attempted to address your comments, but you're
 right - this is a hard thing to find the correct wording for.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.00703561b0efe0afb3da8390a3de2b36%40djangoproject.com.

Re: [Django] #30760: Django admin "view on site" button doesn't respect database routers

[Django]

#30760: Django admin "view on site" button doesn't respect database routers
--+
 Reporter:  zooqooo   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  2.2
 Severity:  Normal|   Resolution:
 Keywords:  Admin, Routers| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Roger Gammans):

 The root cause of this though, the db forcing in
 ContentType.get_object_for_this_type( ) effects otehr users of
 ContentTypes, so its' a content types isses , not really ad admin issue.

 The simple fix is to remove the using(), part of the call chain, which was
 added in for multi db support, but it's not clear , at least to me, why it
 was considered necessary. This which will work in this case and in the
 single db case.

 Arguably it might cause a problem in some other cases, but in general I
 can't see ay strong arguments for overriding the db router.

 I propose at the least we should have a version of
 get_object_for_this_type() , and get_alL_objects_for_this_type() which
 don't include the using clause, however, we may wish to leave the default
 behaviour as is for backward compatiblity.

 Whether that two new functions or we use a kwarg, I don't have s trong
 opinion myself on.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.53a0b428455dbaf4d62e1cb9710d6b8b%40djangoproject.com.

Re: [Django] #31827: Add test runner option to show N slowest tests

[Django]

#31827: Add test runner option to show N slowest tests
-+-
 Reporter:  Ahmad A. Hussein |Owner:  Ahmad A.
 |  Hussein
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ahmad A. Hussein):

 * owner:  nobody => Ahmad A. Hussein
 * status:  new => assigned


Old description:

> Per discussion on [https://github.com/django/django/pull/13224/
> ticket-31811], this option would give developer's an insight into which
> tests need to be sped up.

New description:

 Per discussion on [https://github.com/django/django/pull/13224/
 ticket-31811], this option would give developer's an insight into which
 tests need to be sped up. Needs ticket 31811 to be resolved first.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.47ecafc02d13ffc5035ff1c49244672d%40djangoproject.com.

[Django] #31827: Add test runner option to show N slowest tests

[Django]

#31827: Add test runner option to show N slowest tests
-+
   Reporter:  Ahmad A. Hussein   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Per discussion on [https://github.com/django/django/pull/13224/
 ticket-31811], this option would give developer's an insight into which
 tests need to be sped up.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.ba8249e1b7c6eafb6c7df3605e5d597b%40djangoproject.com.

Re: [Django] #31826: AlterField with only db_column changed should be a noop

[Django]

#31826: AlterField with only db_column changed should be a noop
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Iuri de Silvio:

Old description:

> When I change: `pink = models.Integer(default=0)` to `pink =
> models.Integer(default=0, db_column="pink")` the migration recreate
> constraints if it is an FK or even reconstruct the table (SQLite), but
> nothing really changed.
>
> The (same) constraint drop/create is a blocking operation for PostgreSQL,
> so it is an undesirable and unexpected behavior.

New description:

 When I change `pink = models.Integer(default=0)` to `pink =
 models.Integer(default=0, db_column="pink")` the migration drop/create the
 same constraints when it is an FK or even reconstruct the table (SQLite),
 but nothing really changed. The constraint drop/create is a blocking
 operation for PostgreSQL, so it is an undesirable and unexpected behavior.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8a5fd2360173862c8df4a03965b0a21f%40djangoproject.com.

Re: [Django] #31826: AlterField with only db_column changed should be a noop

[Django]

#31826: AlterField with only db_column changed should be a noop
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Iuri de Silvio:

Old description:

> When I change: `pink = models.Integer(default=0)` to `pink =
> models.Integer(default=0, db_column="pink")` the migration can recreate
> constraints if it is an FK or even reconstruct the table (SQLite).
>
> The (same) constraint drop/create is a blocking operation for PostgreSQL,
> so it is an undesirable and unexpected behavior.

New description:

 When I change: `pink = models.Integer(default=0)` to `pink =
 models.Integer(default=0, db_column="pink")` the migration recreate
 constraints if it is an FK or even reconstruct the table (SQLite), but
 nothing really changed.

 The (same) constraint drop/create is a blocking operation for PostgreSQL,
 so it is an undesirable and unexpected behavior.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.92332d84b1a103763669646a8cff1f1d%40djangoproject.com.

Re: [Django] #31826: AlterField with only db_column changed should be a noop

[Django]

#31826: AlterField with only db_column changed should be a noop
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Iuri de Silvio):

 * owner:  nobody => Iuri de Silvio
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.2e814097bb98d7ee20f41682c67065b9%40djangoproject.com.

Re: [Django] #31826: AlterField with only db_column changed should be a noop

[Django]

#31826: AlterField with only db_column changed should be a noop
-+-
 Reporter:  Iuri de Silvio   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Iuri de Silvio):

 I sent a pull request here. https://github.com/django/django/pull/13237

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.08482c30b5efc046c72f65a865f70275%40djangoproject.com.

[Django] #31826: AlterField with only db_column changed should be a noop

[Django]

#31826: AlterField with only db_column changed should be a noop
+
   Reporter:  Iuri de Silvio|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Migrations|Version:  3.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 When I change: `pink = models.Integer(default=0)` to `pink =
 models.Integer(default=0, db_column="pink")` the migration can recreate
 constraints if it is an FK or even reconstruct the table (SQLite).

 The (same) constraint drop/create is a blocking operation for PostgreSQL,
 so it is an undesirable and unexpected behavior.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.5aebd96142fdc453bad754329bfdf11d%40djangoproject.com.

Re: [Django] #31825: RenameField with db_column defined drop and recreate the same constrainsts on Postgres

[Django]

#31825: RenameField with db_column defined drop and recreate the same 
constrainsts
on Postgres
-+-
 Reporter:  iurisilvio   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by iurisilvio):

 I did a pull request here. https://github.com/django/django/pull/13236

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.08aaecfa3ef51938e489509a7640%40djangoproject.com.

Re: [Django] #31825: RenameField with db_column defined drop and recreate the same constrainsts on Postgres

[Django]

#31825: RenameField with db_column defined drop and recreate the same 
constrainsts
on Postgres
-+-
 Reporter:  iurisilvio   |Owner:
 Type:   |  iurisilvio
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by iurisilvio):

 * owner:  nobody => iurisilvio
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.665ca61ca2a3746f28b970be28644e20%40djangoproject.com.

Re: [Django] #31825: RenameField with db_column defined drop and recreate the same constrainsts on Postgres (was: RenameField with db_column defined drop and recreate the same constrainsts)

[Django]

#31825: RenameField with db_column defined drop and recreate the same 
constrainsts
on Postgres
-+-
 Reporter:  iurisilvio   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by iurisilvio:

Old description:

> RenameField with db_column should be a noop because it is only the Dajngo

New description:

 RenameField with db_column should be a noop because it is only the Django
 column that changed, the database still have the same db_column.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.56abafecaa897086ccd22ba31818d617%40djangoproject.com.

[Django] #31825: RenameField with db_column defined drop and recreate the same constrainsts

[Django]

#31825: RenameField with db_column defined drop and recreate the same 
constrainsts
+
   Reporter:  iurisilvio|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Migrations|Version:  3.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 RenameField with db_column should be a noop because it is only the Dajngo

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.99d3e393df2403fd764a0ad8b07790b5%40djangoproject.com.