Re: [Django] #26423: Make EmailValidator use HTML5 validation rather than more complicated regular expressions

[Django]

#26423: Make EmailValidator use HTML5 validation rather than more complicated
regular expressions
--+
 Reporter:  Tim Graham|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 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 Tim Graham):

 * status:  assigned => new
 * owner:  Chris Butler => (none)


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

Re: [Django] #26487: Use EHLO after smtplib.SMTP_SSL too.

[Django]

#26487: Use EHLO after smtplib.SMTP_SSL too.
--+
 Reporter:  kchmiela  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Mail)   |  Version:  master
 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
--+

Comment (by GitHub ):

 In [changeset:"bcae045de01588debe49b266a07a5bfb95068679" bcae045d]:
 {{{
 #!CommitTicketReference repository=""
 revision="bcae045de01588debe49b266a07a5bfb95068679"
 Refs #26487 -- Removed unneeded ehlo() calls in SMTP backend.

 starttls(), login(), and other connection methods already call
 the method as needed.
 }}}

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

Re: [Django] #26487: Use EHLO after smtplib.SMTP_SSL too.

[Django]

#26487: Use EHLO after smtplib.SMTP_SSL too.
-+-
 Reporter:  kchmiela |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:  needsinfo
 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 Tim Graham):

 * status:  new => closed
 * 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.804151a8652f72df1b52cf76fa266ba6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25012: Migration doesn't seem to detect foreignKey type changes

[Django]

#25012: Migration doesn't seem to detect foreignKey type changes
-+
 Reporter:  Hedde van der Heide  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 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 Aleksi Häkli):

 I was able to neatly fix this with a raw SQL migration that changed the
 intermediary table column type.

 I had the following schema in an application called `documents`:


 {{{
 class Tag(models.Model):
 # converted this `name` field to primary_key
 # previously had the default `id` AutoField as primary_key field
 # PrimaryKeyField migration in for ManyToManyField is risky!
 name = models.CharField(max_length=32, primary_key=True)

 class Document(models.Model):
 tags = models.ManyToManyField(Tag, blank=True)
 }}}


 After changing the schema and running unit tests I discovered that I
 indeed to got a DatabaseError:

 {{{
 django.db.utils.DataError: invalid input syntax for integer: "Miss Amanda
 Goodwin"
 LINE 1: ..."tag_id") WHERE "documents_document_tags"."tag_id" = 'Miss
 Aman...
 }}}

 Migrating with the following helped:

 {{{
 ALTER TABLE documents_document_tags ALTER COLUMN tag_id TYPE varchar(32);
 }}}

 This of course had to be added as a migration file for sane functionality
 in tests and migration chain:

 {{{
 # -*- coding: utf-8 -*-
 # Migrations file example for fixing broken ManyToManyField migration from
 INTEGER to VARCHAR
 # Generated by Django 1.10.3 on 1970-01-01 00:00
 from __future__ import unicode_literals

 from django.db import migrations

 class Migration(migrations.Migration):
 dependencies = [
 ('documents', '0042_auto_19700101-'),
 ]

 operations = [
 migrations.RunSQL('ALTER TABLE documents_document_tags ALTER
 tag_id TYPE varchar(32);'),
 ]
 }}}

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

Re: [Django] #27624: Optimize ORM by using more immutable data structures

[Django]

#27624: Optimize ORM by using more immutable data structures
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 Adam Chainz):

 Tim, I will be looking at changing some more of the attributes after the
 current two PR's are merged, please keep the ticket open for a bit ;)

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

Re: [Django] #18823: Clear with a M2M field with a through model

[Django]

#18823: Clear with a M2M field with a through model
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"b8741c005873396de24a085fe9ab13d2348a306b" b8741c00]:
 {{{
 #!CommitTicketReference repository=""
 revision="b8741c005873396de24a085fe9ab13d2348a306b"
 Refs #18823 -- Corrected field name in an m2m manager error message.
 }}}

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

Re: [Django] #18823: Clear with a M2M field with a through model

[Django]

#18823: Clear with a M2M field with a through model
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"39a884380226e3ae372cdc93b7227ad2c8e7b086" 39a88438]:
 {{{
 #!CommitTicketReference repository=""
 revision="39a884380226e3ae372cdc93b7227ad2c8e7b086"
 Used assertRaisesMessage() in m2m_through_regress tests.

 The "needs to have a value for field" messages are incorrect and
 reference nonexistent fields since the commit in which they were
 introduced (refs #18823).
 }}}

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

Re: [Django] #27624: Optimize ORM by using more immutable data structures

[Django]

#27624: Optimize ORM by using more immutable data structures
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 Tim Graham ):

 In [changeset:"6ebf8f9057893b802fa85599573886081f32edc9" 6ebf8f90]:
 {{{
 #!CommitTicketReference repository=""
 revision="6ebf8f9057893b802fa85599573886081f32edc9"
 Refs #27624 -- Made QuerySet._prefetch_related_lookups immutable.
 }}}

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

Re: [Django] #27626: Move MEDIA_URL/STATIC_URL ends with traling slash validation to system checks

[Django]

#27626: Move MEDIA_URL/STATIC_URL ends with traling slash validation to system
checks
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  1.10
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"8669cf0e684696971f6b577f5023634cb16f307e" 8669cf0]:
 {{{
 #!CommitTicketReference repository=""
 revision="8669cf0e684696971f6b577f5023634cb16f307e"
 Fixed #27626 -- Moved MEDIA_URL/STATIC_URL validation to a system check.
 }}}

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

Re: [Django] #27625: Make Settings avoid repeat getattr calls

[Django]

#27625: Make Settings avoid repeat getattr calls
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  1.10
 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
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"c1b221a9b913315998a1bcec2f29a9361a74d1ac" c1b221a9]:
 {{{
 #!CommitTicketReference repository=""
 revision="c1b221a9b913315998a1bcec2f29a9361a74d1ac"
 Fixed #27625 -- Made LazySettings cache attributes in __dict__.
 }}}

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

Re: [Django] #14297: Accessing settings.FOO in hot spots cause performance problems

[Django]

#14297: Accessing settings.FOO in hot spots cause performance problems
-+-
 Reporter:  Anssi Kääriäinen |Owner:  (none)
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  settings,| Triage Stage:  Accepted
  performance|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Chainz):

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


Comment:

 Duplicate of #27625

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

[Django] #27627: OneToOneField doesn't allow multiple records with NULL value on Microsoft SQL Server

[Django]

#27627: OneToOneField doesn't allow multiple records with NULL value on 
Microsoft
SQL Server
-+
   Reporter:  Ryan Schave|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:
   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  |
-+
 A OneToOneField with null=True should allow multiple records to be saved
 with a NULL value in the field.  Consider the following models:

 {{{
 class Company(models.Model):
 name = models.CharField(max_length=30)


 class UserProfile(models.Model):
 case_manager = models.BooleanField(default=False)
 company = models.OneToOneField(Company, models.SET_NULL, blank=True,
 null=True)
 }}}

 With a SQLite or PostgreSQL backend I'm able to save multiple records with
 a NULL value:

 {{{
 up1 = UserProfile.objects.create(case_manager=True)
 up2 = UserProfile.objects.create(case_manager=False)
 }}}

 With Microsoft SQL Server, the 2nd attempt to create a record with a NULL
 value results in an integrity error:

 django.db.utils.IntegrityError: ('23000', "[23000] [Microsoft][SQL Server
 Native Client 11.0][SQL Server]Violation of UNIQUE KEY constraint
 'UQ__contacts__3E2672343AF86B58'. Cannot insert duplicate key in object
 'dbo.contacts_userprofile'. The duplicate key value is (). (2627)
 (SQLExecDirectW)")

 This post - http://stackoverflow.com/a/767702 describes the problem and
 suggests creating a "unique filtered index based on a predicate that
 excludes NULLs".

 I have confirmed that if I manually remove the constraint created by the
 migration in the table schema and create a unique filtered index that
 excludes NULLs on the company field I can create multiple records with a
 NULL value in the company field.  The migration should be adding a filter
 to the index that looks something like:

 {{{
 WHERE ([company_id] IS NOT NULL)
 }}}

 I am able to duplicate the problem with Django 1.9.10 and 1.10.4.

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

[Django] #27628: startproject with template as a github zipball fails with PermissionError

[Django]

#27628: startproject with template as a github zipball fails with 
PermissionError
---+
   Reporter:  Karen Tracey |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Utilities|Version:  master
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Using current master, on Ubuntu 16.04 with Python 3.5, a startproject
 command of the form:

 `django-admin.py startproject --template=https://github.com/caktus/django-
 project-template/zipball/master --extension=py,rst,yml
 --name=Makefile,gulpfile.js,package.json newproject`

 is failing with PermissionError:

 {{{
 --> ~/software/django/django/bin/django-admin.py startproject
 --template=https://github.com/caktus/django-project-
 template/zipball/master --extension=py,rst,yml
 --name=Makefile,gulpfile.js,package.json newproject
 Traceback (most recent call last):
   File "/home/kmtracey/software/django/django/bin/django-admin.py", line
 5, in 
 management.execute_from_command_line()
   File
 "/home/kmtracey/software/django/django/core/management/__init__.py", line
 357, in execute_from_command_line
 utility.execute()
   File
 "/home/kmtracey/software/django/django/core/management/__init__.py", line
 349, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/kmtracey/software/django/django/core/management/base.py",
 line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/kmtracey/software/django/django/core/management/base.py",
 line 330, in execute
 output = self.handle(*args, **options)
   File
 
"/home/kmtracey/software/django/django/core/management/commands/startproject.py",
 line 34, in handle
 super(Command, self).handle('project', project_name, target,
 **options)
   File
 "/home/kmtracey/software/django/django/core/management/templates.py", line
 163, in handle
 with io.open(old_path, 'r', encoding='utf-8') as template_file:
 PermissionError: [Errno 13] Permission denied:
 '/tmp/django_project_template_0llqnt13_extract/fabfile.py'
 }}}

 Inspecting the leftover extracted "archive" all files extracted have mode
 000. Unzipping the leftover zipfile using the os unzip command results in
 files that are "-rw-rw-r--".

 This appears to be due to new code added for #26494 which is setting the
 file mode based on the value of a zipinfo external_attr value...however in
 my case this external_attr value is 0 and none of the extracted file can
 subsequently be opened by the remainder of the startproject command code.

 {{{
 --> ~/software/django/django/bin/django-admin.py startproject
 --template=https://github.com/caktus/django-project-
 template/zipball/master --extension=py,rst,yml
 --name=Makefile,gulpfile.js,package.json newproject
 > /home/kmtracey/software/django/django/utils/archive.py(205)extract()
 -> mode = info.external_attr >> 16
 (Pdb) info
 
 (Pdb) info.external_attr
 0
 (Pdb)
 }}}

 Setting as a release blocker since this is a regression from 1.10, where
 the same command works fine. I think the fix for #26494 needs revisiting
 since apparently external_attr isn't always usefully set (doc seems
 nonexistent in Python for this attribute??).

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

Re: [Django] #26494: executable flags lost when using an archive as a project/app template

[Django]

#26494: executable flags lost when using an archive as a project/app template
--+
 Reporter:  Jakub Dorňák  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Karen Tracey):

 #27628 has been opened to note a regression introduced by this fix.

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

Re: [Django] #27627: OneToOneField doesn't allow multiple records with NULL value on Microsoft SQL Server

[Django]

#27627: OneToOneField doesn't allow multiple records with NULL value on 
Microsoft
SQL Server
-+-
 Reporter:  Ryan Schave  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 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 Tim Graham):

 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Is it certain that Django must be fixed rather than the MSSQL database
 backend that you're using? (which one is it?) In any case, adding a test
 to Django's test suite to confirm that all built-in backends behave
 properly seems like a good idea. Hopefully database backend that you're
 using will also run that test.

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

Re: [Django] #27627: OneToOneField doesn't allow multiple records with NULL value on Microsoft SQL Server

[Django]

#27627: OneToOneField doesn't allow multiple records with NULL value on 
Microsoft
SQL Server
-+-
 Reporter:  Ryan Schave  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 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 Simon Charette):

 I'm pretty sure that's a bug in the MSSQL server backend used by the
 reporter here.

 MSSQL server diverges from the SQL standard by disallowing multiple `NULL`
 values in column with a `UNIQUE` index. The backend should make sure to
 create conditional indexes excluding `NULL` columns for fields marked
 `null=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.0a0accf91de80ef3676265e2b5a8ccb9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Andrey
 Type:   |  Kuzminov
  Cleanup/optimization   |   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:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

Re: [Django] #27498: Filtering annotated field in SQLite returns wrong results

[Django]

#27498: Filtering annotated field in SQLite returns wrong results
-+-
 Reporter:  Tim Düllmann |Owner:  Peter
 |  Inglesby
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite,  | Triage Stage:  Accepted
  annotations, filter|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

Re: [Django] #27628: startproject with template as a github zipball fails with PermissionError

[Django]

#27628: startproject with template as a github zipball fails with 
PermissionError
-+
 Reporter:  Karen Tracey |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  master
 Severity:  Release blocker  |   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 Tim Graham):

 * stage:  Unreviewed => Accepted


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

[Django] #27629: Inconsistent check of allow_relation in ForwardManyToOneDescriptor.__set__

[Django]

#27629: Inconsistent check of allow_relation in 
ForwardManyToOneDescriptor.__set__
-+-
   Reporter:  Sven   |  Owner:  nobody
  Coenye |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|   Keywords:  allow_relation
   Severity:  Normal |  ForwardManyToOneDescriptor
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The method in  django/db/models/fields/related_descriptors.py currently
 contains the following code:
 {{{
 if instance._state.db is None:
 instance._state.db = router.db_for_write(instance.__class__,
 instance=value)
 elif value._state.db is None:
 value._state.db = router.db_for_write(value.__class__,
 instance=instance)
 elif value._state.db is not None and instance._state.db is not None:
 if not router.allow_relation(value, instance):
 raise ValueError('Cannot assign "%r": the current database router
 prevents this relation.' % value)
 }}}

 When using an application containing the following model
 {{{
 from otherapp.models import AdProgram

 class Order(models.Model):
 first_name   = models.CharField(max_length = 15)
 last_name= models.CharField(max_length = 20)
 program  = models.ForeignKey(AdProgram, db_constraint=False)#
 No cross database FK constraints under MSSQL
 }}}

 where the imported model belongs to a legacy database different from the
 application's own database, the code in question does not flag an
 inappropriate relationship. E.g. when submitting a ModelForm containing
 these three fields, the value for program will be saved to the
 application's database even if allow_relation would return False.

 When the model definition is changed to
 {{{
 from otherapp.models import AdProgram, AdTerm

 class Order(models.Model):
 first_name   = models.CharField(max_length = 15)
 last_name= models.CharField(max_length = 20)
 program  = models.ForeignKey(AdProgram, db_constraint=False)#
 No cross database FK constraints under MSSQL
 term = models.ForeignKey(AdTerm, db_constraint=False)
 }}}

 "program" again gets a free pass, but "term" triggers the ValueError
 exception.

 The reason is that instance._state.db is None for the "program" field but
 contains the value retrieved for "program" for any subsequent fields.

 I believe those "elif" statements should be plain "if" statements so the
 uninitialized value on the first pass does not fall through?

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

Re: [Django] #27629: Inconsistent check of allow_relation in ForwardManyToOneDescriptor.__set__

[Django]

#27629: Inconsistent check of allow_relation in 
ForwardManyToOneDescriptor.__set__
-+-
 Reporter:  Sven Coenye  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  allow_relation   | Triage Stage:  Accepted
  ForwardManyToOneDescriptor |
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:

 That code hasn't changed since multiple database support was introduced in
 Django 1.2 (1b3dc8ad9a28486542f766ff93318aa6b4f5999b) but you may be
 correct -- at least no tests are failing with the proposed change so
 that's a good sign.

 I was going to make the claim that that code might be written based on
 [https://docs.djangoproject.com/en/stable/topics/db/multi-db/#cross-
 database-relations this assumption] in the documentation:

  However, if you’re using SQLite or MySQL with MyISAM tables, there is no
 enforced referential integrity; as a result, you may be able to ‘fake’
 cross database foreign keys. However, this configuration is not officially
 supported by Django.

 but I'm not positive about that.

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

Re: [Django] #26543: Changelist actions don't redirect after failed action resulting in possible ERR_CACHE_MISS in next steps

[Django]

#26543: Changelist actions don't redirect after failed action resulting in 
possible
ERR_CACHE_MISS in next steps
-+-
 Reporter:  Emmanuelle   |Owner:  Adonys
  Delescolle |  Alea Boffill
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"8ba01d1e42bfb49cfea323a7f23365a819b16214" 8ba01d1]:
 {{{
 #!CommitTicketReference repository=""
 revision="8ba01d1e42bfb49cfea323a7f23365a819b16214"
 Fixed #26543 -- Prevented "confirm form submission" browser prompt when
 reloading after an admin actions failure.
 }}}

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

[Django] #27630: Autoreload continuously reloads when not using pyinotify

[Django]

#27630: Autoreload continuously reloads when not using pyinotify
-+
   Reporter:  zatricion  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  master
   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  |
-+
 In
 https://github.com/django/django/blob/master/django/utils/autoreload.py,
 the function `code_changed` uses `st_mtime` without taking into account
 floating point errors, which in some cases can cause `runserver` to reload
 over and over again.

 For instance:
  $ [os.stat(file).st_mtime for file in os.listdir(os.getcwd())[:3]]
  [1464887244.822038, 1482518222.822038, 1464887244.822038]
  $ [os.stat(file).st_mtime for file in os.listdir(os.getcwd())[:3]]
  [1464887244.380515, 1482518222.380515, 1464887244.380515]
  $ [os.stat(file).st_mtime for file in os.listdir(os.getcwd())[:3]]
  [1464887244.1597567, 1482518222.1597567, 1464887244.1597567]

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

Re: [Django] #27630: Autoreload continuously reloads when not using pyinotify

[Django]

#27630: Autoreload continuously reloads when not using pyinotify
+--
 Reporter:  Michael Lauria  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  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 Tim Graham):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Utilities


Comment:

 It sounds like you're doing nothing on your computer and runserver is
 reloading over and over -- is that correct?

 Could you add some more details? The code snippet doesn't help me to
 understand the issue. 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/067.067e0faaacc0c16e637181fb16998dff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27630: Autoreload continuously reloads when not using pyinotify

[Django]

#27630: Autoreload continuously reloads when not using pyinotify
+--
 Reporter:  Michael Lauria  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  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
+--

Comment (by Michael Lauria):

 Actually I think this is an issue with Docker and not Django. The issue is
 that the timestamps change a little every time in a mounted volume, like
 so:

 Access: 2016-12-24 00:08:37.118410672 +
 Modify: 2016-12-24 00:08:35.118410672 +
 Change: 2016-12-24 00:08:35.118410672 +

 Access: 2016-12-24 00:08:37.117298381 +
 Modify: 2016-12-24 00:08:35.117298381 +
 Change: 2016-12-24 00:08:35.117298381 +

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

Re: [Django] #27630: Autoreload continuously reloads when not using pyinotify

[Django]

#27630: Autoreload continuously reloads when not using pyinotify
+--
 Reporter:  Michael Lauria  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Utilities   |  Version:  master
 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
 * resolution:   => invalid


Comment:

 Okay, feel free to reopen with more details if Django is found to be at
 fault.

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

Re: [Django] #26384: Migrations crash renaming the pk of a model with a self-referential foreign key on SQLite

[Django]

#26384: Migrations crash renaming the pk of a model with a self-referential 
foreign
key on SQLite
-+
 Reporter:  Brian May|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Simon Charette ):

 In [changeset:"96181080bae66ee4f4e6d52bddcd57fa420a929b" 96181080]:
 {{{
 #!CommitTicketReference repository=""
 revision="96181080bae66ee4f4e6d52bddcd57fa420a929b"
 Refs #26384 -- Isolated a test model in schema tests.
 }}}

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

[Django] #27631: Prevent execution of transactionnal DDL statements when unsupported.

[Django]

#27631: Prevent execution of transactionnal DDL statements when unsupported.
--+
   Reporter:  Simon Charette  |  Owner:  Simon Charette
   Type:  Bug | Status:  assigned
  Component:  Migrations  |Version:  master
   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   |
--+
 Executing a DDL statement during a transaction on backends that don't
 support it silently commits, leaving `atomic()` in an incoherent state.

 While `schema_editor.execute()` could technically be used to execute DML
 statements such usage should be uncommon as these are usually performed
 through the ORM. In other cases `schema_editor.connection.execute()` can
 be used to circumvent this check.

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

Re: [Django] #27631: Prevent execution of transactionnal DDL statements when unsupported.

[Django]

#27631: Prevent execution of transactionnal DDL statements when unsupported.
+--
 Reporter:  Simon Charette  |Owner:  Simon Charette
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 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 Simon Charette):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7737 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 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.a9590f3ea4e971abac252c61ec771a66%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21837: auth.User Email - non-RFC spec case normalization (was: auth.User Email - non-RFC spec normalization)

[Django]

#21837: auth.User Email - non-RFC spec case normalization
-+-
 Reporter:  ross@…   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  authentication,  | Triage Stage:  Accepted
  email, filter, get, error  |
  nlsprint14 |
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/073.688f1a76687c6b1fbb591dcabdfb4b11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27632: Oracle backend fails to execute a query with an aggregation that contains an expression in the GROUP BY.

[Django]

#27632: Oracle backend fails to execute a query with an aggregation that 
contains
an expression in the GROUP BY.
-+-
   Reporter:  Josh   |  Owner:  nobody
  Smeaton|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  oracle
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Oracle fails on queries where there is an expression containing replace
 parameters in the SELECT list and GROUP BY list, because the database
 appears to check the SELECT and GROUP BY match **before** doing parameter
 substitution.

 Parameters in cx_Oracle follow the form `:arg0` and `:arg1` or named as
 `:price` and `:discount`. Since the arguments in the SELECT and GROUP BY
 have a different argument number, the database rejects the query with the
 following error:

 {{{
 *** django.db.utils.DatabaseError: ORA-00979: not a GROUP BY expression
 }}}

 Failing test for aggregation_regress:

 {{{
 Book.objects.annotate(
 discount_price=F('price') * 0.75
 ).values(
 'discount_price'
 ).annotate(sum_discount=Sum('price'))
 }}}

 SQL and parameters:

 {{{
 'SELECT
 ("AGGREGATION_REGRESS_BOOK"."PRICE" * :arg0) AS "DISCOUNT_PRICE",
 SUM("AGGREGATION_REGRESS_BOOK"."PRICE") AS "SUM_DISCOUNT"
 FROM "AGGREGATION_REGRESS_BOOK"
 GROUP BY ("AGGREGATION_REGRESS_BOOK"."PRICE" * :arg1),
 "AGGREGATION_REGRESS_BOOK"."NAME"
 ORDER BY "AGGREGATION_REGRESS_BOOK"."NAME" ASC'

 args: (0.75, 0.75)
 }}}

 Django can't really do a whole lot here without changing parameter
 substitution to use named arguments, or by somehow keeping track of what
 parameter positions are bound to which expression, and reusing the
 argument names when the Oracle backend replaces the "%s" placeholders with
 the ":argN" format that cx_Oracle requires. In either case, it'd involve a
 very large refactoring, and even then I'm not sure how feasible it would
 be.

 I *think* this is a problem that should be solved by Oracle. If anyone is
 able to find any references to this bug in Oracle documentation or systems
 I'd love to see it. As I don't work for a company using Oracle anymore,
 I'm not able to utilise support to investigate further.

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