date:20190201

Re: [Django] #30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" when altering pk of model with ForeignKey to self

2019-02-01 Thread Django

#30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" 
when
altering pk of model with ForeignKey to self
---+
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords:  mysql  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * status:  closed => new
 * resolution:  needsinfo =>


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.84abe7c4fd870295cebbac41082db2a5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" when altering pk of model with ForeignKey to self

2019-02-01 Thread Django

#30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" 
when
altering pk of model with ForeignKey to self
---+-
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  mysql  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by Carsten Fuchs):

 Ah, slowly I get the hang of working with migrations in this way!  :-)
 Sorry about the extra fields. Also the meta `db_table` doesn't contribute.
 The minimum models.py file I've managed to find is:

 {{{
 #!python
 class Kostenstelle(models.Model):
 # id = models.AutoField(primary_key=True)
 id = models.IntegerField(primary_key=True, help_text="...")
 parent = models.ForeignKey('self', models.PROTECT, null=True,
 blank=True)


 class KalenderEintrag(models.Model):
 id  = models.AutoField(primary_key=True)
 kst = models.ManyToManyField(Kostenstelle, blank=True)
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0ef3bfeeccb2cba40829fa379acaf42d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" when altering pk of model with ForeignKey to self (was: MySQL: Cannot change column 'id': used in a foreign ke

2019-02-01 Thread Django

#30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" 
when
altering pk of model with ForeignKey to self
---+-
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  mysql  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Great! I think there are still some unnecessary fields on the models
 (DateField, etc) but my guess is the ForeignKey to self plus another model
 related to that one (ManyToManyField in this case) are the root causes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2a4c799b2340c1d9846d1c53b73a8058%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

2019-02-01 Thread Django

#30152: MySQL: Cannot change column 'id': used in a foreign key constraint
---+--
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  mysql  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carsten Fuchs):

 Hi Tim,
 many thanks for your work!

 I've been able to come up with a small example with which I can reproduce
 this.
 Please see the three attached files `models.py` and the migrations
 `0001_initial.py` and `0002_auto_20190201_2242.py`.

 {{{
 #!sh
 (TestDjango22a) carsten@black-steel-ubuntu:~/ticket30152$ ./manage.py
 --version
 2.2a1

 (TestDjango22a) carsten@black-steel-ubuntu:~/ticket30152$ ./manage.py
 startapp Lori

 # settings.py edited

 (TestDjango22a) carsten@black-steel-ubuntu:~/ticket30152$ ./manage.py
 makemigrations
 Migrations for 'Lori':
   Lori/migrations/0001_initial.py
 - Create model Kostenstelle
 - Create model KalenderEintrag

 # changed `id` field definition

 (TestDjango22a) carsten@black-steel-ubuntu:~/ticket30152$ ./manage.py
 makemigrations
 Migrations for 'Lori':
   Lori/migrations/0002_auto_20190201_2242.py
 - Alter field id on kostenstelle

 (TestDjango22a) carsten@black-steel-ubuntu:~/ticket30152$ ./manage.py
 migrate
 Operations to perform:
   Apply all migrations: Lori, admin, auth, contenttypes, sessions
 Running migrations:
   Applying Lori.0001_initial… OK
   Applying Lori.0002_auto_20190201_2242…Traceback (most recent call last):
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/django/db/backends/mysql/base.py", line 71, in execute
 return self.cursor.execute(query, args)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 198, in execute
 res = self._query(query)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 304, in _query
 db.query(q)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/MySQLdb/connections.py", line 217, in query
 _mysql.connection.query(self, query)
 MySQLdb._exceptions.OperationalError: (1833, "Cannot change column 'id':
 used in a foreign key constraint
 'Lori_kalendereintrag_kostenstelle_id_bcd99894_fk_kostenste' of table
 'LoriDB.Lori_kalendereintrag_kst'")

 The above exception was the direct cause of the following exception:
 # ...
 }}}

 Can you please have a look if you can reproduce it with these files?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bedbdd9537aad73c801db0bf57e8f249%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

2019-02-01 Thread Django

#30152: MySQL: Cannot change column 'id': used in a foreign key constraint
---+--
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  mysql  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carsten Fuchs):

 * Attachment "0002_auto_20190201_2242.py" 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a99c0d63814908bc05e52a5b52a56940%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

2019-02-01 Thread Django

#30152: MySQL: Cannot change column 'id': used in a foreign key constraint
---+--
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  mysql  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carsten Fuchs):

 * Attachment "0001_initial.py" 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.5eab14f76b214dec17e73b0c40631d1a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

2019-02-01 Thread Django

#30152: MySQL: Cannot change column 'id': used in a foreign key constraint
---+--
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  mysql  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carsten Fuchs):

 * Attachment "models.py" added.

 Test case model definitions

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a96f1d0bb78d51c2e4df73e5bcb6acf7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

2019-02-01 Thread Django

#30152: MySQL: Cannot change column 'id': used in a foreign key constraint
---+--
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  2.2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  mysql  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Database layer (models, ORM) => Migrations
 * type:  Uncategorized => Bug


Comment:

 I can't reproduce this using the information provided:
 {{{
 $ python manage.py makemigrations
 Migrations for 't30152':
   t30152/migrations/0001_initial.py
 - Create model Kostenstelle
 }}}
 (changed field as from `AutoField` to `IntegerField`)
 {{{
 $ python manage.py makemigrations
 Migrations for 't30152':
   t30152/migrations/0002_auto_20190201_2147.py
 - Alter field id on kostenstelle
 $ python manage.py migrate
 Operations to perform:
   Apply all migrations: admin, aggregation, auth, contenttypes, generic,
 polls, proxytest, sessions, t30152
 Running migrations:
   Applying t30152.0001_initial… OK
   Applying t30152.0002_auto_20190201_2147… OK
 }}}
 You'll need to provide more information.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.38e303fd7604d70d928006c1c1a256df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

2019-02-01 Thread Django

#30152: MySQL: Cannot change column 'id': used in a foreign key constraint
-+-
 Reporter:  Carsten Fuchs|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> As outlined for Django 1.11.18 at https://groups.google.com/d/msg/django-
> users/3L5deYDtDMU/jRixojr7DgAJ, the problem can be reproduced with Django
> 2.2a1 in a fresh database.
> Possibly related is #28305, which sounds very similar.
>
> Using a model like this:
> {{{
> #!python
> class Kostenstelle(models.Model):
> id = models.AutoField(primary_key=True)
> name = models.CharField(max_length=60, blank=True)
> # ... omitted fields
>
> class Meta:
> db_table = 'kostenstelle'
> }}}
>
> I replaced the `id` line with
>
> {{{
> #!python
> id = models.IntegerField(primary_key=True, help_text="...")
> }}}
>
> Running `manage.py makemigrations` (of Django 1.11.1) created two
> migration files, numbers 0022 and 0023:
> {{{
> #!python
> # Migration 0022 (import statements omitted).
> class Migration(migrations.Migration):
>
> dependencies = [
> ('Lori', '0021_alter_Vortraege_jahr'),
> ]
>
> operations = [
> migrations.AlterField(
> model_name='kostenstelle',
> name='id',
> field=models.IntegerField(primary_key=True, serialize=False),
> ),
> ]
> }}}
>
> {{{
> #!python
> # Migration 0023 (import statements omitted).
> class Migration(migrations.Migration):
>
> dependencies = [
> ('Lori', '0022_alter_Kostenstelle_id'),
> ]
>
> operations = [
> migrations.AlterField(
> model_name='kostenstelle',
> name='id',
> field=models.IntegerField(help_text='...', primary_key=True,
> serialize=False),
> ),
> ]
> }}}
>
> These used to work properly with the Oracle DB backend, but with Django
> 2.2a1 with MySQL backend, there are problems:
>
> {{{
> #!sh
> (TestDjango22a) carsten@black-steel-ubuntu:~/Zeiterfassung$ # starting
> with a fresh MySQL database
> (TestDjango22a) carsten@black-steel-ubuntu:~/Zeiterfassung$ ./manage.py
> --version
> 2.2a1
> (TestDjango22a) carsten@black-steel-ubuntu:~/Zeiterfassung$ ./manage.py
> migrate
> Operations to perform:
>   Apply all migrations: Lori, admin, auth, contenttypes, sessions
> Running migrations:
>   Applying contenttypes.0001_initial… OK
>   Applying auth.0001_initial… OK
>   Applying Lori.0001_initial… OK
>   Applying Lori.0002_alter_Ausbezahlt_monat… OK
>   Applying Lori.0003_alter_Kalendereintrag_m2m… OK
>   Applying Lori.0004_del_Erfasst_kann_gg… OK
>   Applying Lori.0005_add_Mitarbeiter_email… OK
>   Applying Lori.0006_create_UserBereichZuordnung… OK
>   Applying Lori.0007_init_UserBereichZuordnung… OK
>   Applying Lori.0008_del_Bereich_benutzer… OK
>   Applying Lori.0009_add_Bereich_benutzer… OK
>   Applying Lori.0010_create_UserKstZuordnung… OK
>   Applying Lori.0011_init_UserKstZuordnung… OK
>   Applying Lori.0012_del_Kostenstelle_benutzer… OK
>   Applying Lori.0013_add_Kostenstelle_benutzer… OK
>   Applying Lori.0014_refine_UserZuordnungen… OK
>   Applying Lori.0015_add_UserBereichZuordnung_darf_urlantr… OK
>   Applying Lori.0016_add_Mitarbeiter_anschrift… OK
>   Applying Lori.0017_create_PekoSollStd… OK
>   Applying Lori.0018_alter_Vortraege_jahr… OK
>   Applying Lori.0019_alter_UserProfile_ma… OK
>   Applying Lori.0020_del_PekoGewichte… OK
>   Applying Lori.0021_alter_Vortraege_jahr… OK
>   Applying Lori.0022_alter_Kostenstelle_id…Traceback (most recent call
> last):
>   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
> packages/django/db/backends/utils.py", line 84, in _execute
> return self.cursor.execute(sql, params)
>   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
> packages/django/db/backends/mysql/base.py", line 71, in execute
> return self.cursor.execute(query, args)
>   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
> packages/MySQLdb/cursors.py", line 198, in execute
> res = self._query(query)
>   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
> packages/MySQLdb/cursors.py", line 304, in _query
> db.query(q)
>   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
> packages/MySQLdb/connections.py", line 217, in

[Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

2019-02-01 Thread Django

#30152: MySQL: Cannot change column 'id': used in a foreign key constraint
-+-
   Reporter:  Carsten|  Owner:  nobody
  Fuchs  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  mysql
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 As outlined for Django 1.11.18 at https://groups.google.com/d/msg/django-
 users/3L5deYDtDMU/jRixojr7DgAJ, the problem can be reproduced with Django
 2.2a1 in a fresh database.
 Possibly related is #28305, which sounds very similar.

 Using a model like this:
 {{{
 #!python
 class Kostenstelle(models.Model):
 id = models.AutoField(primary_key=True)
 name = models.CharField(max_length=60, blank=True)
 # ... omitted fields

 class Meta:
 db_table = 'kostenstelle'
 }}}

 I replaced the `id` line with

 {{{
 #!python
 id = models.IntegerField(primary_key=True, help_text="...")
 }}}

 Running `manage.py makemigrations` (of Django 1.11.1) created two
 migration files, numbers 0022 and 0023:
 {{{
 #!python
 # Migration 0022 (import statements omitted).
 class Migration(migrations.Migration):

 dependencies = [
 ('Lori', '0021_alter_Vortraege_jahr'),
 ]

 operations = [
 migrations.AlterField(
 model_name='kostenstelle',
 name='id',
 field=models.IntegerField(primary_key=True, serialize=False),
 ),
 ]
 }}}

 {{{
 #!python
 # Migration 0023 (import statements omitted).
 class Migration(migrations.Migration):

 dependencies = [
 ('Lori', '0022_alter_Kostenstelle_id'),
 ]

 operations = [
 migrations.AlterField(
 model_name='kostenstelle',
 name='id',
 field=models.IntegerField(help_text='...', primary_key=True,
 serialize=False),
 ),
 ]
 }}}

 These used to work properly with the Oracle DB backend, but with Django
 2.2a1 with MySQL backend, there are problems:

 {{{
 #!sh
 (TestDjango22a) carsten@black-steel-ubuntu:~/Zeiterfassung$ # starting
 with a fresh MySQL database
 (TestDjango22a) carsten@black-steel-ubuntu:~/Zeiterfassung$ ./manage.py
 --version
 2.2a1
 (TestDjango22a) carsten@black-steel-ubuntu:~/Zeiterfassung$ ./manage.py
 migrate
 Operations to perform:
   Apply all migrations: Lori, admin, auth, contenttypes, sessions
 Running migrations:
   Applying contenttypes.0001_initial… OK
   Applying auth.0001_initial… OK
   Applying Lori.0001_initial… OK
   Applying Lori.0002_alter_Ausbezahlt_monat… OK
   Applying Lori.0003_alter_Kalendereintrag_m2m… OK
   Applying Lori.0004_del_Erfasst_kann_gg… OK
   Applying Lori.0005_add_Mitarbeiter_email… OK
   Applying Lori.0006_create_UserBereichZuordnung… OK
   Applying Lori.0007_init_UserBereichZuordnung… OK
   Applying Lori.0008_del_Bereich_benutzer… OK
   Applying Lori.0009_add_Bereich_benutzer… OK
   Applying Lori.0010_create_UserKstZuordnung… OK
   Applying Lori.0011_init_UserKstZuordnung… OK
   Applying Lori.0012_del_Kostenstelle_benutzer… OK
   Applying Lori.0013_add_Kostenstelle_benutzer… OK
   Applying Lori.0014_refine_UserZuordnungen… OK
   Applying Lori.0015_add_UserBereichZuordnung_darf_urlantr… OK
   Applying Lori.0016_add_Mitarbeiter_anschrift… OK
   Applying Lori.0017_create_PekoSollStd… OK
   Applying Lori.0018_alter_Vortraege_jahr… OK
   Applying Lori.0019_alter_UserProfile_ma… OK
   Applying Lori.0020_del_PekoGewichte… OK
   Applying Lori.0021_alter_Vortraege_jahr… OK
   Applying Lori.0022_alter_Kostenstelle_id…Traceback (most recent call
 last):
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/django/db/backends/mysql/base.py", line 71, in execute
 return self.cursor.execute(query, args)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 198, in execute
 res = self._query(query)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 304, in _query
 db.query(q)
   File "/home/carsten/.virtualenvs/TestDjango22a/lib/python3.6/site-
 packages/MySQLdb/connections.py", line 217, in query
 _mysql.connection.query(self, query)
 MySQLdb._exceptions.OperationalError: (1833, "Cannot change column 'id':
 used in a foreign key constraint
 'L

Re: [Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

2019-02-01 Thread Django

Comment (by Carsten Fuchs):

Well, it's probably only me, but this puts me into a somewhat precarious
situation:
Django 1.11 supports Oracle 11 and MySQL 5*, but not Oracle 12 or MySQL 8.
Django 2 supports Oracle 12 and MySQL 8, but not Oracle 11.

As I intend to switch from Oracle 11 to MySQL, the only supported upgrade
path that is left is:
Django 1.11 with Oracle 11 --> Django 1.11 with MySQL 5.7 --> Django 2.0
with MySQL 5.7 --> Django 2.0 with MySQL 8 --> Django 2.1 with MySQL 8.

I'll probably take the risk and use MySQL 8 right from the start anyways,
but I wished there had been a milder step possible.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.a2af6a28fba1eed992de4b1acf9a82cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

2019-02-01 Thread Django

#30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"
-+-
 Reporter:  Carsten Fuchs|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 Tim Graham):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Per the [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy], 1.1.11.x only receives
 data loss and security fixes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2d219001d2465f10aee24abc95894914%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

2019-02-01 Thread Django

#30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"
-+-
 Reporter:  Carsten Fuchs|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-

Comment (by Tim Graham ):

 In [changeset:"951ee0b118eb640e6484189117be3308417d87bd" 951ee0b1]:
 {{{
 #!CommitTicketReference repository=""
 revision="951ee0b118eb640e6484189117be3308417d87bd"
 [1.11.x] Refs #30150 -- Doc'd that MySQL 8 isn't supported.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c2d8c8d6e77821632a363d40ab7d4879%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30151: QuerySet.last() and [] operator give different results (was: last() and [] operator give different results)

2019-02-01 Thread Django

#30151: QuerySet.last() and [] operator give different results
-+-
 Reporter:  NMO13|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 Tim Graham):

 * status:  new => closed
 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => Bug
 * resolution:   => invalid


Comment:

 As far as I can tell from the code you gave, the slice is operating on an
 unordered queryset. There's no guarantee as to what ordering the database
 will return. `last()` gives ordering by primary key if the queryset isn't
 ordered.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5c05025411d7558e338bb441e0caa134%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30151: last() and [] operator give different results

2019-02-01 Thread Django

#30151: last() and [] operator give different results
---+--
 Reporter:  NMO13  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.11
 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 NMO13:

Old description:

> I have a model RSSFeed. To get the last element in my DB, I do:
>

> {{{
> RSSFeed.objects.last()
> # Output: 
> }}}
>

> I slice it to get the first 10 element in the query
>

> {{{
> first_ten_feeds = RSSFeed.objects.all()[:10]
> }}}
>

> Using first and the bracket operator is consistent:
>
> first_ten_feeds.first()
> # Output: 
> first_ten_feeds[0]
> # Output: 
>
> But using last and the bracket operator is not consistent:
>

> {{{
> first_ten_feeds[9]
> # Output:  Dienstleistungen>
>
> first_ten_feeds.last()
> # Output: 
> }}}
>

> Why? I expect to get the same result for last() and [] above.
>

>
> RSSFeed.objects.last() and first_ten_feeds.last() seem to give the same
> result but that does not make sense to me.
>
> I already openend a SO question with the same content:
> https://stackoverflow.com/questions/54477472/last-and-operator-give-
> different-results
> There I was suggested to open a bug.

New description:

 I have a model RSSFeed. To get the last element in my DB, I do:


 {{{
 RSSFeed.objects.last()
 # Output: 
 }}}


 I slice it to get the first 10 element in the query


 {{{
 first_ten_feeds = RSSFeed.objects.all()[:10]
 }}}


 Using first and the bracket operator is consistent:


 {{{
 first_ten_feeds.first()
 # Output: 
 first_ten_feeds[0]
 # Output: 
 }}}


 But using last and the bracket operator is not consistent:


 {{{
 first_ten_feeds[9]
 # Output: 

 first_ten_feeds.last()
 # Output: 
 }}}


 Why? I expect to get the same result for last() and [] above.



 RSSFeed.objects.last() and first_ten_feeds.last() seem to give the same
 result but that does not make sense to me.

 I already openend a SO question with the same content:
 https://stackoverflow.com/questions/54477472/last-and-operator-give-
 different-results
 There I was suggested to open a bug.

--

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.1fd2bea046a86f6ac8b48bc6649e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30151: last() and [] operator give different results

2019-02-01 Thread Django

#30151: last() and [] operator give different results
---+--
 Reporter:  NMO13  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.11
 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 NMO13:

Old description:

> I have a model RSSFeed. To get the last element in my DB, I do:
>

> {{{
> RSSFeed.objects.last()
> # Output: 
> }}}
>

> I slice it to get the first 10 element in the query
>

> {{{
> first_ten_feeds = RSSFeed.objects.all()[:10]
> }}}
>

> Using first and the bracket operator is consistent:
>
> first_ten_feeds.first()
> # Output: 
> first_ten_feeds[0]
> # Output: 
>
> But using last and the bracket operator is not consistent:
>

> {{{
> first_ten_feeds[9]
> # Output:  Dienstleistungen>
>
> first_ten_feeds.last()
> # Output: 
> }}}
>

> Why? I expect to get the same result for last() and [] above.
>

>
> RSSFeed.objects.last() and first_ten_feeds.last()
>
>  seem to give the same result but that does not make sense to me.
>
> I already openend a SO question with the same content:
> https://stackoverflow.com/questions/54477472/last-and-operator-give-
> different-results
> There I was suggested to open a bug.

New description:

 I have a model RSSFeed. To get the last element in my DB, I do:


 {{{
 RSSFeed.objects.last()
 # Output: 
 }}}


 I slice it to get the first 10 element in the query


 {{{
 first_ten_feeds = RSSFeed.objects.all()[:10]
 }}}


 Using first and the bracket operator is consistent:

 first_ten_feeds.first()
 # Output: 
 first_ten_feeds[0]
 # Output: 

 But using last and the bracket operator is not consistent:


 {{{
 first_ten_feeds[9]
 # Output: 

 first_ten_feeds.last()
 # Output: 
 }}}


 Why? I expect to get the same result for last() and [] above.



 RSSFeed.objects.last() and first_ten_feeds.last() seem to give the same
 result but that does not make sense to me.

 I already openend a SO question with the same content:
 https://stackoverflow.com/questions/54477472/last-and-operator-give-
 different-results
 There I was suggested to open a bug.

--

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.4e86e3921b24cfc6ea1bbaa62fb74ca2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30151: last() and [] operator give different results

2019-02-01 Thread Django

#30151: last() and [] operator give different results
-+
   Reporter:  NMO13  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.11
   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 have a model RSSFeed. To get the last element in my DB, I do:


 {{{
 RSSFeed.objects.last()
 # Output: 
 }}}


 I slice it to get the first 10 element in the query


 {{{
 first_ten_feeds = RSSFeed.objects.all()[:10]
 }}}


 Using first and the bracket operator is consistent:

 first_ten_feeds.first()
 # Output: 
 first_ten_feeds[0]
 # Output: 

 But using last and the bracket operator is not consistent:


 {{{
 first_ten_feeds[9]
 # Output: 

 first_ten_feeds.last()
 # Output: 
 }}}


 Why? I expect to get the same result for last() and [] above.



 RSSFeed.objects.last() and first_ten_feeds.last()

  seem to give the same result but that does not make sense to me.

 I already openend a SO question with the same content:
 https://stackoverflow.com/questions/54477472/last-and-operator-give-
 different-results
 There I was suggested to open a bug.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.2122ec93491c036cb35f7324064f01ae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

2019-02-01 Thread Django

#30128: Using database functions with
tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect
query
-+-
 Reporter:  mvarnar  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, postgresql, | Triage Stage:  Accepted
  timezone, datetime |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * owner:  nobody => Can Sarıgöl
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6648633673234271d7b17cfba3575892%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30064: Admin search with a null character crashes with "A string literal cannot contain NUL (0x00) characters." on PostgreSQL

2019-02-01 Thread Django

#30064: Admin search with a null character crashes with "A string literal cannot
contain NUL (0x00) characters." on PostgreSQL
---+---
 Reporter:  kenichi-cc |Owner:  Can Sarıgöl
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  2.1
 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 Can Sarıgöl):

 * owner:  nobody => Can Sarıgöl
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.9c7aa223d68623c9f6577d6cd14a6120%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

2019-02-01 Thread Django

#30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"
-+-
   Reporter:  Carsten|  Owner:  nobody
  Fuchs  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  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  |
-+-
 https://docs.djangoproject.com/en/1.11/ref/databases/#version-support
 suggests that Django 1.11 works with MySQL 8, but besides #29451, there is
 a problem similar to #28804 and #28794:

 {{{
 #!sh
 $ python manage.py check --deploy
 Traceback (most recent call last):
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 62, in execute
 return self.cursor.execute(sql)
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/django/db/backends/mysql/base.py", line 101, in execute
 return self.cursor.execute(query, args)
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 250, in execute
 self.errorhandler(self, exc, value)
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/MySQLdb/connections.py", line 50, in defaulterrorhandler
 raise errorvalue
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 247, in execute
 res = self._query(query)
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 412, in _query
 rowcount = self._do_query(q)
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/MySQLdb/cursors.py", line 375, in _do_query
 db.query(q)
   File "/home/carsten/.virtualenvs/Zeiterfassung/lib/python3.6/site-
 packages/MySQLdb/connections.py", line 276, in query
 _mysql.connection.query(self, query)
 _mysql_exceptions.OperationalError: (1193, "Unknown system variable
 'TX_ISOLATION'")

 The above exception was the direct cause of the following exception:

 [...]
 }}}

 This can be worked-around by changing line 289 in
 `db/backends/mysql/base.py`
 {{{
 assignments.append("TX_ISOLATION = '%s'" %
 self.isolation_level)
 }}}
 into
 {{{
 assignments.append("transaction_isolation = '%s'" %
 self.isolation_level)
 }}}

 Any chance to get this, with proper checks for the MySQL version, into
 Django 1.11?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.c316cfb33e039cde24e38768a11897e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18012: Propagate reverse foreign keys from proxy models to base class

2019-02-01 Thread Django

#18012: Propagate reverse foreign keys from proxy models to base class
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ivan):

 {{{
 class Worker(models.Model):

 fio = models.CharField(u'ФИО', unique=True, max_length=250)
 active = models.BooleanField(default=True, help_text="Активный")

 def __str__(self):
 return self.fio

 class WorkerActive(Worker):

 def __str__(self):
 if not self.active:
 return "%s (Не кативен)" % (self.fio,)
 return self.fio

 class Meta:
 proxy = True

 class License(models.Model):
 target_workers = models.ManyToManyField(WorkerActive,
 verbose_name="Покупалась для", blank=True)

 def __str__(self):
 return u"License for %s (%s)" % (self.soft.name, self.number or
 '')

 }}}



 I have error (1054, "Unknown column
 'inventory_license_target_workers.workeractive_id' in 'field list'")
 WHY!?
 I believe that this is a gross error of the concept of using Proxy models

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7dc6d164b4d8ced9406123c9f5ca53f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter

2019-02-01 Thread Django

#28687: Add a 'Not Empty' option to admin's related filter
-+-
 Reporter:  Brillgen Developers  |Owner:  Jake
 Type:   |  Barber
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sardorbek Imomaliev):

 Hi Carlton,

 Thanks for reply, it is not broken because there is no `Not Empty` choice
 in django itself
 created new issue https://code.djangoproject.com/ticket/30149

 Replying to [comment:11 Carlton Gibson]:
 > Hi Sardorbek.
 >
 > This looks like a (related but) separate issue. Can you submit a new
 ticket, something along the lines of "Empty value `selected` check in
 Admin Filter prevents subclassing" and we can have a look.
 >
 > At first glance I can't see how both `bool(self.lookup_val_isnull)` and
 `self.lookup_val_isnull == 'False'` evaluate as `True` in the `Not Empty`
 case. (???) Surely the existing `empty_choice` logic would already be
 broken if they did.
 >
 > If you have a PR (with a test case showing the broken example) available
 (or can provide one when opening the ticket) it makes it much easier to
 assess.
 >
 > Thanks.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a2339a1996e00097868c5486aa5b797f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30149: Empty value selected check in Admin Filter prevents subclassing (was: "Empty value selected check in Admin Filter prevents subclassing")

2019-02-01 Thread Django

#30149: Empty value selected check in Admin Filter prevents subclassing
-+-
 Reporter:  Sardorbek Imomaliev  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  admin| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ce5e1e2431b08168a0c79248388ead8a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30149: "Empty value selected check in Admin Filter prevents subclassing"

2019-02-01 Thread Django

#30149: "Empty value selected check in Admin Filter prevents subclassing"
---+
   Reporter:  Sardorbek Imomaliev  |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  contrib.admin|Version:  2.1
   Severity:  Normal   |   Keywords:  admin
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 as per https://code.djangoproject.com/ticket/28687?cnum_edit=10#comment:11
 creating new issue, will get to writing test and PR next week

 Currently to add `Not Empty` choice you need to do this

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   class NotEmptyFilter(admin.RelatedFieldListFilter):
   @property
   def include_empty_choice(self):
   # FIXME: empty value selected incorrectly override in choices
   return False

   def has_output(self):
   return super().has_output() + 2

   def choices(self, changelist):
   yield from super().choices(changelist)
   yield {
   'selected': self.lookup_val_isnull == 'True',
   'query_string': changelist.get_query_string(
   {self.lookup_kwarg_isnull: 'True'}, [self.lookup_kwarg]
   ),
   'display': _('Empty'),
   yield {
   'selected': self.lookup_val_isnull == 'False',
   'query_string': changelist.get_query_string(
   {self.lookup_kwarg_isnull: 'False'}, [self.lookup_kwarg]
   ),
   'display': _('Not Empty'),
   }
   }}}
 }}}

 But you should be able to do just
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   class NotEmptyFilter(admin.RelatedFieldListFilter):
   def has_output(self):
   return super().has_output() + 1

   def choices(self, changelist):
   yield from super().choices(changelist)
   yield {
   'selected': self.lookup_val_isnull == 'False',
   'query_string': changelist.get_query_string(
   {self.lookup_kwarg_isnull: 'False'}, [self.lookup_kwarg]
   ),
   'display': _('Not Empty'),
   }
   }}}
 }}}

 Currently this is not possible because of `bool(self.lookup_val_isnull)`
 check in selected for `Empty` choice, and if we add `Not Empty` choice
 like in second example we will get both `Empty` and `Not Empty` choices
 rendered as selected on `Not Empty`

 This is easy to fix, and I would like to provide PR if this change is OK

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.4624a07f1e0b3996d8290e2b5571877b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" when altering pk of model with ForeignKey to self

Re: [Django] #30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" when altering pk of model with ForeignKey to self

Re: [Django] #30152: MySQL: "Cannot change column 'id': used in a foreign key constraint" when altering pk of model with ForeignKey to self (was: MySQL: Cannot change column 'id': used in a foreign ke

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

Re: [Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

[Django] #30152: MySQL: Cannot change column 'id': used in a foreign key constraint

Re: [Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

Re: [Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

Re: [Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

Re: [Django] #30151: QuerySet.last() and [] operator give different results (was: last() and [] operator give different results)

Re: [Django] #30151: last() and [] operator give different results

Re: [Django] #30151: last() and [] operator give different results

[Django] #30151: last() and [] operator give different results

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

Re: [Django] #30064: Admin search with a null character crashes with "A string literal cannot contain NUL (0x00) characters." on PostgreSQL

[Django] #30150: Django 1.11 with MySQL 8: "Unknown system variable 'TX_ISOLATION'"

Re: [Django] #18012: Propagate reverse foreign keys from proxy models to base class

Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter

Re: [Django] #30149: Empty value selected check in Admin Filter prevents subclassing (was: "Empty value selected check in Admin Filter prevents subclassing")

[Django] #30149: "Empty value selected check in Admin Filter prevents subclassing"

24 matches

Site Navigation

Mail list logo

Footer information