Re: [Django] #28809: Changing SRID on geometry field doesn't create working migration

[Django]

#28809: Changing SRID on geometry field doesn't create working migration
-+-
 Reporter:  Jani Tiainen |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations gis   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * status:  new => assigned
 * owner:  nobody => Sergey Fedoseev


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

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'"

[Django]

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sergey Fedoseev):

 Replying to [comment:9 Tim Graham]:
 > As far as I see, we'd still need transaction_isolation/tx_isolation for
 the test which queries `SELECT @@transaction_isolation`. Did I miss
 something?

 What's was the reason why I didn't use `SET TRANSACTION ISOLATION LEVEL`,
 but do we really need to test it?

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

Re: [Django] #28783: Support for custom operator class for indexes

[Django]

#28783: Support for custom operator class for indexes
-+-
 Reporter:  vinay karanam|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, operator   | Triage Stage:
  class  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vinay karanam):

 AFAICT, this is only supported on psql. I am unable to find similar
 feature on other databases.

 I've updated the corresponding documentation.

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

Re: [Django] #28810: Use the Python 3-esque str.format logging formatting style over '%'

[Django]

#28810: Use the Python 3-esque str.format logging formatting style over '%'
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.11
 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
-+-

Comment (by Chris Lamb):

 Replying to [comment:2 Tim Graham]:
 > I'm not sure why you say "Python 3-esque str.format" in the description.
 `str.format()` was added in Python 2.6.

 I should have used a better suffix than "esque" — it's more that Python 3
 code does tend to *prefer* `str.format` over `%`-style interpolation
 simply as a correlation with it being more modern/newer in general. ie. if
 it's "new enough" for Python 3, it's probably going to be using
 newer/nicer features. It's therefore somewhat surprising to see the
 reverse, hence this proposed change.

 > there's a consensus against using mandating `str.format()` usage
 everwhere in Django and prohibiting the `%s` syntax.

 As it happens, I would be against such a total mandate and a widespread
 change *within* Django, but this is more of a user-exposed thing so a
 different, separate argument IMHO.

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

Re: [Django] #25002: Postgresql migration fails when changing a CharField to a TimeField

[Django]

#25002: Postgresql migration fails when changing a CharField to a TimeField
+-
 Reporter:  Dirk Uys|Owner:  Simon Charette
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  migrations  | 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):

 * component:  Database layer (models, ORM) => Migrations


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

Re: [Django] #28816: Silent data loss when decreasing the max_length of a CharField

[Django]

#28816: Silent data loss when decreasing the max_length of a CharField
+
 Reporter:  Gavin Wahl  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.11
 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:  Database layer (models, ORM) => Migrations
 * 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/067.def6f464b4017938fa3548c048508721%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28810: Use the Python 3-esque str.format logging formatting style over '%'

[Django]

#28810: Use the Python 3-esque str.format logging formatting style over '%'
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.11
 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
-+-

Old description:

> We currently use the ``%(foo)s`` style in Django and in docs.  This
> "smells" quite Python 2.x when there is a ``str.format`` variety that
> uses, eg. ``{foo}``.

New description:

 We currently use the `%(foo)s` style in Django and in docs.  This "smells"
 quite Python 2.x when there is a `str.format` variety that uses, eg.
 `{foo}`.

--

Comment (by Tim Graham):

 I'm not sure why you say "Python 3-esque str.format" in the description.
 `str.format()` was added in Python 2.6. I see that logging support for
 that style (by using `style='{'`) was added in Python 3.2.

 I'm not opposed to the change, as it seems like a slight readability
 enhancement, although generally I think there's a consensus against using
 mandating `str.format()` usage everwhere in Django and prohibiting the
 `%s` syntax. I think there was a ticket but I can't find it at the moment.

 My only concern with the proposal is whether it could break backwards
 compatibility. I see an update to `ServerFormatter.uses_server_time()` was
 required. I'm not sure if it's likely that user code may make similar
 assumptions about the format string.

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

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'"

[Django]

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 As far as I see, we'd still need transaction_isolation/tx_isolation for
 the test which queries `SELECT @@transaction_isolation`. Did I miss
 something?

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

Re: [Django] #28815: Incorrect ExtractYear imports in Window functions docs (was: Docs outdated after django.db.models.functions introduced)

[Django]

#28815: Incorrect ExtractYear imports in Window functions docs
-+-
 Reporter:  benjaoming   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 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:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Ready for checkin


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

Re: [Django] #28815: Docs outdated after django.db.models.functions introduced

[Django]

#28815: Docs outdated after django.db.models.functions introduced
---+--
 Reporter:  benjaoming |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"385e06d8c05ad4e5089295a3bafad2b922fd2763" 385e06d]:
 {{{
 #!CommitTicketReference repository=""
 revision="385e06d8c05ad4e5089295a3bafad2b922fd2763"
 [2.0.x] Fixed #28815 -- Fixed ExtractYear imports in
 docs/ref/models/expressions.txt.

 Backport of bf49d9eb0b33aefc7179d3843fad0cb7df4e7790 from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.c587d160137955fb6452d02c64779cf3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28815: Docs outdated after django.db.models.functions introduced

[Django]

#28815: Docs outdated after django.db.models.functions introduced
---+--
 Reporter:  benjaoming |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"bf49d9eb0b33aefc7179d3843fad0cb7df4e7790" bf49d9eb]:
 {{{
 #!CommitTicketReference repository=""
 revision="bf49d9eb0b33aefc7179d3843fad0cb7df4e7790"
 Fixed #28815 -- Fixed ExtractYear imports in
 docs/ref/models/expressions.txt.
 }}}

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

Re: [Django] #28814: Python 3.7 compatibility

[Django]

#28814: Python 3.7 compatibility
--+-
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Someday/Maybe
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:"5b21e3983dfce04251dbb795a70859c1ee78db8e" 5b21e398]:
 {{{
 #!CommitTicketReference repository=""
 revision="5b21e3983dfce04251dbb795a70859c1ee78db8e"
 [2.0.x] Refs #28814 -- Fixed test_runner failure on Python 3.7.

 Due to https://bugs.python.org/issue30399.

 Backport of 9d1d3b2d2fe0bef995b024368088eeabbdf73629 from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.2015e0ceede1c5edfe8a91ab4f5fee12%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28814: Python 3.7 compatibility

[Django]

#28814: Python 3.7 compatibility
--+-
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Someday/Maybe
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:"9d1d3b2d2fe0bef995b024368088eeabbdf73629" 9d1d3b2d]:
 {{{
 #!CommitTicketReference repository=""
 revision="9d1d3b2d2fe0bef995b024368088eeabbdf73629"
 Refs #28814 -- Fixed test_runner failure on Python 3.7.

 Due to https://bugs.python.org/issue30399.
 }}}

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

[Django] #28816: Silent data loss when decreasing the max_length of a CharField

[Django]

#28816: Silent data loss when decreasing the max_length of a CharField
-+-
   Reporter:  Gavin  |  Owner:  nobody
  Wahl   |
   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  |
-+-
 I have a CharField that I want to decrease the max_length on. I change the
 value and generate a migration, then run it on my database.

 Desired:

 I should get an error from postgres if existing data doesn't fit in the
 new length:

   ERROR:  value too long for type character varying(5)

 Observed:

 Any existing data longer than the new_max length is truncated and lost.

 This behavior was introducted in #25002, which unconditionally added a
 cast to the new type. This changes the default behavior of postgres (which
 is to never lose data), to implicitly truncate. Django should not lose
 data by default.

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

Re: [Django] #28815: Docs outdated after django.db.models.functions introduced

[Django]

#28815: Docs outdated after django.db.models.functions introduced
---+--
 Reporter:  benjaoming |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by benjaoming:

Old description:

> Documentation has the wrong location of `ExtractYear`:
>
> https://docs.djangoproject.com/en/2.0/ref/models/expressions/#window-
> functions
>
> Example:
>
> {{{
> >>> from django.db.models import Avg, ExtractYear, F, Window
> Traceback (most recent call last):
>   File "", line 1, in 
> from django.db.models import Avg, ExtractYear, F, Window
> ImportError: cannot import name 'ExtractYear'
> }}}
>
> Should these functions be available from `django.db.models`? The module
> already contains quite a heavy load of imports

New description:

 Documentation has the wrong location of `ExtractYear`:

 https://docs.djangoproject.com/en/2.0/ref/models/expressions/#window-
 functions

 Example:

 {{{
 >>> from django.db.models import Avg, ExtractYear, F, Window
 Traceback (most recent call last):
   File "", line 1, in 
 from django.db.models import Avg, ExtractYear, F, Window
 ImportError: cannot import name 'ExtractYear'
 }}}

 Should these functions be available from `django.db.models`? The module
 already contains quite a heavy load of imports

 References:

 `django.db.models.functions.datetime` created in:
 
https://github.com/django/django/commit/77b73e79a4750dcbfabc528bf00cad81ff5bb4d9

 Window expression PR:
 https://github.com/django/django/pull/7611/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/068.74e51326224497e28dc707d7b57769ca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28815: Docs outdated after django.db.models.functions introduced

[Django]

#28815: Docs outdated after django.db.models.functions introduced
-+
   Reporter:  benjaoming |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Documentation has the wrong location of `ExtractYear`:

 https://docs.djangoproject.com/en/2.0/ref/models/expressions/#window-
 functions

 Example:

 {{{
 >>> from django.db.models import Avg, ExtractYear, F, Window
 Traceback (most recent call last):
   File "", line 1, in 
 from django.db.models import Avg, ExtractYear, F, Window
 ImportError: cannot import name 'ExtractYear'
 }}}

 Should these functions be available from `django.db.models`? The module
 already contains quite a heavy load of imports

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

Re: [Django] #28814: Python 3.7 compatibility

[Django]

#28814: Python 3.7 compatibility
--+-
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Someday/Maybe
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:"8e63cc582f8ab66e5d8a94a72b6d12eb4c7e85e6" 8e63cc58]:
 {{{
 #!CommitTicketReference repository=""
 revision="8e63cc582f8ab66e5d8a94a72b6d12eb4c7e85e6"
 [2.0.x] Refs #28814 -- Fixed "SyntaxError: Generator expression must be
 parenthesized" on Python 3.7.

 Due to https://bugs.python.org/issue32012.

 Backport of 931c60c5216bd71bc11f489e00e063331cf21f40 from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.b97f32a50e72c0be0fe643f311303e4a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28814: Python 3.7 compatibility

[Django]

#28814: Python 3.7 compatibility
--+-
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Someday/Maybe
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:"931c60c5216bd71bc11f489e00e063331cf21f40" 931c60c5]:
 {{{
 #!CommitTicketReference repository=""
 revision="931c60c5216bd71bc11f489e00e063331cf21f40"
 Refs #28814 -- Fixed "SyntaxError: Generator expression must be
 parenthesized" on Python 3.7.

 Due to https://bugs.python.org/issue32012.
 }}}

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

Re: [Django] #28798: Remove unused django.utils.dates.WEEKDAYS_REV, MONTHS_3_REV

[Django]

#28798: Remove unused django.utils.dates.WEEKDAYS_REV, MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  dates| 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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"648957b707491b99dc32a3cdbeaaa3fe9f3164cf" 648957b]:
 {{{
 #!CommitTicketReference repository=""
 revision="648957b707491b99dc32a3cdbeaaa3fe9f3164cf"
 Fixed #28798 -- Removed unused django.utils.dates.WEEKDAYS_REV,
 MONTHS_3_REV.
 }}}

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

Re: [Django] #28813: Sqlite migration of manual primary key

[Django]

#28813: Sqlite migration of manual primary key
+--
 Reporter:  cecedille1  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.11
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  sqlite  | 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:   => duplicate


Comment:

 Duplicate of #24424.

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

Re: [Django] #28814: Python 3.7 compatibility

[Django]

#28814: Python 3.7 compatibility
--+-
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Someday/Maybe
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by felixxm):

 * cc: felixxm (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/067.8ac873aa48fa4949a24d8504e2677812%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28814: Python 3.7 compatibility

[Django]

#28814: Python 3.7 compatibility
-+
   Reporter:  Tim Graham |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Core (Other)   |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Someday/Maybe  |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Python 3.7 final is scheduled for June 2018. This is a tracking ticket for
 compatibility fixes for Django submitted in the meantime.

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

Re: [Django] #28813: Sqlite migration of manual primary key

[Django]

#28813: Sqlite migration of manual primary key
+--
 Reporter:  cecedille1  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  sqlite  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by cecedille1):

 One way to fix this  is to create the new field first before removing the
 old one

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

[Django] #28813: Sqlite migration of manual primary key

[Django]

#28813: Sqlite migration of manual primary key
--+
   Reporter:  cecedille1  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  1.11
   Severity:  Normal  |   Keywords:  sqlite
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Sqlite migration generates an invalid INSERT INTO clause when a table has
 no more columns. (happens with manual primary keys)

 {{{
 BEGIN;
 --
 -- Remove field f1 from poc
 --
 ALTER TABLE "app_poc" RENAME TO "app_poc__old";
 CREATE TABLE "app_poc" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT);
 INSERT INTO "app_poc" () SELECT  FROM "app_poc__old";
 DROP TABLE "app_poc__old";
 --
 -- Add field f2 to poc
 --
 ALTER TABLE "app_poc" RENAME TO "app_poc__old";
 CREATE TABLE "app_poc" ("f2" integer NOT NULL PRIMARY KEY);
 INSERT INTO "app_poc" ("f2") SELECT 1 FROM "app_poc__old";
 DROP TABLE "app_poc__old";
 COMMIT;
 }}}
 https://github.com/cecedille1/django-migrate-empty-columns-poc

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

Re: [Django] #28514: Clarify docs regarding idempotence of RelatedManager.add()

[Django]

#28514: Clarify docs regarding idempotence of RelatedManager.add()
-+-
 Reporter:  Дилян Палаузов   |Owner:  Jezeniel
 Type:   |  Zapanta
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 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
-+-

Comment (by Дилян Палаузов):

 I don't think that the ON CONFLICT DO NOTHING change will get into Django
 2.0, even if #28668 was fixed yesterday.

 Under these circumstances for the next year or so  {{{.add(one more
 elements)}}} can raise an {{{IntegrityError}}} or send wrong m2m_changed
 signals and this should be documented.

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

Re: [Django] #28809: Changing SRID on geometry field doesn't create working migration

[Django]

#28809: Changing SRID on geometry field doesn't create working migration
+
 Reporter:  Jani Tiainen|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  migrations gis  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Sergey Fedoseev):

 * cc: Sergey Fedoseev (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/063.c9c3152ac6f96c40404bd0eb9701ad35%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:  Stefan R.
 |  Filipek
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  allow_relation   | Triage Stage:  Accepted
  ForwardManyToOneDescriptor |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 "Ready for checkin" is set by a patch reviewer, not the patch author (see
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/ Triaging tickets]).

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

Re: [Django] #28798: Remove unused django.utils.dates.WEEKDAYS_REV, MONTHS_3_REV (was: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV)

[Django]

#28798: Remove unused django.utils.dates.WEEKDAYS_REV, MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| 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):

 * stage:  Unreviewed => Ready for checkin
 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.2f452b4a3d80e8f64c4142f6138e5b15%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28812: Lack of ModelAdmin permission to list all objects.

[Django]

#28812: Lack of ModelAdmin permission to list all objects.
---+--
 Reporter:  Priest |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  permissions| 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:   => duplicate


Comment:

 Duplicate of #8936 "Add view (read-only) permission to admin".

-- 
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/064.12bcd33286c6a554889ba331b8bcb813%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:  Stefan R.
 |  Filipek
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  allow_relation   | Triage Stage:  Ready for
  ForwardManyToOneDescriptor |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Stefan R. Filipek):

 * version:  1.10 => 1.11
 * stage:  Accepted => Ready for checkin


Comment:

 Pull request against master: https://github.com/django/django/pull/9360

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

Re: [Django] #28800: List routes in the console

[Django]

#28800: List routes in the console
---+--
 Reporter:  Martín Peveri  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Core (URLs)|  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
---+--

Comment (by Martín Peveri):

 I like what I say Keryn Knight. If approved, I could work on the ticket
 and send a 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/066.cd8e9b36286fdd209dc48488e8add286%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28812: Lack of ModelAdmin permission to list all objects.

[Django]

#28812: Lack of ModelAdmin permission to list all objects.
-+-
   Reporter:  ksiadz |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  1.11
   Severity:  Normal |   Keywords:  permissions
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Listing all objects permission is connected to permission called:
 "has_change_permission". There is missing permission for listing all
 objects that we have permissions.

 I suggest name as:
 "has_list_permission"
 It could take argument whether to display all objects or only these that
 has_change_permission returns True (sounds as default option), but also
 has_delete_permission and has_add_permission should be taken under
 consideration.

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

Re: [Django] #28809: Changing SRID on geometry field doesn't create working migration

[Django]

#28809: Changing SRID on geometry field doesn't create working migration
+
 Reporter:  Jani Tiainen|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  migrations gis  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Jani Tiainen):

 True, SRID change migrations is not easy to do (might not even be possible
 sometimes due missing conversion parameters). But case should be handled
 much more gracefully than throwing out traceback.

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

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'"

[Django]

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * cc: Sergey Fedoseev (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/065.a937662e042f0d4825c76b248b4dd3c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'"

[Django]

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 We can use the `SET TRANSACTION ISOLATION LEVEL` statement rather than the
 variable

 https://mariadb.com/kb/en/library/set-transaction/
 https://dev.mysql.com/doc/refman/5.5/en/set-transaction.html

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

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'"

[Django]

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gene Sem):

 After some debugging with MariaDB:

 Function `mysql_version()` returned value is: 10.0.31 for MariaDB 10.0.31,
 but actually it is equivalent of original mySQL 5.7.0

 So `transaction_isolation_variable()` should return `'tx_isolation'`
 but returning `'transaction_isolation'` which is error value for mariadb.

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

Re: [Django] #28809: Changing SRID on geometry field doesn't create working migration

[Django]

#28809: Changing SRID on geometry field doesn't create working migration
+
 Reporter:  Jani Tiainen|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  migrations gis  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Claude Paroz):

 * version:  1.11 => master
 * component:  Database layer (models, ORM) => GIS
 * stage:  Unreviewed => Accepted


Comment:

 Changing the SRID of a field is something that's hard to do when you have
 existing content. I don't think databases are doing anything clever when
 you do that (e.g. they don't convert the existing values, AFAIK). Probably
 the best strategy is to create a new column, move the values, converting
 them in the new SRID in the process, and delete the old column. The
 strategy might differ depending on the backend.

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

[Django] #28811: KeyError when using a regular annotation inside an F-statement in a group by annotation

[Django]

#28811: KeyError when using a regular annotation inside an F-statement in a 
group
by annotation
-+-
   Reporter:  Robin  |  Owner:  nobody
  Ramael |
   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  |
-+-
 When a queryset is first annotated in the regular way (just adding a
 column), and then that annotation is used inside an F-expression in a
 group by-annotation, the query generation crashes with a KeyError because
 it can't find the first annotation.

 Code to reproduce:

 == models.py:

 {{{

 from django.db import models

 class Data(models.Model):
 option = models.CharField(max_length=2)
 value = models.FloatField()

 }}}


 == tests.py:
 {{{

 from django.db.models import F, Sum, Value
 from django.test import TestCase

 from .models import Data, Thing


 class AnnotateTests(TestCase):

 def test_simple(self):

 Data.objects.create(option='A', value=1)
 Data.objects.create(option='A', value=2)

 Data.objects.create(option='B', value=3)
 Data.objects.create(option='B', value=4)

 data_qs = (Data.objects
.annotate(multiplier=Value(3))   # will of course be
 far more complex in the wild
# group by option => sum of value * multiplier
.values('option')
.annotate(multiplied_value_sum=Sum(F('multiplier') *
 F('value')))
.order_by())

 print(list(data_qs))

 }}}

 There is a workaround, though: replacing the F-expression in the second
 with the value of the first doesn't require the annotation lookup,
 avoiding the KeyError, so the solution for this might just be a better
 error message, although this gets unwieldy for complex annotations.

 Running this test will result in the following traceback:

 {{{
 Creating test database for alias 'default'...
 System check identified no issues (0 silenced).
 E
 ==
 ERROR: test_simple (annotate.tests.AnnotateTests)
 --
 Traceback (most recent call last):
   File "/Users/robin/src/ormweirdness/annotate/tests.py", line 21, in
 test_simple
 .annotate(multiplied_value_sum=Sum(F('multiplier') * F('value')))
   File "/Users/robin/.virtualenvs/ormweirdness/lib/python3.6/site-
 packages/django/db/models/query.py", line 945, in annotate
 clone.query.add_annotation(annotation, alias, is_summary=False)
   File "/Users/robin/.virtualenvs/ormweirdness/lib/python3.6/site-
 packages/django/db/models/sql/query.py", line 973, in add_annotation
 summarize=is_summary)
   File "/Users/robin/.virtualenvs/ormweirdness/lib/python3.6/site-
 packages/django/db/models/aggregates.py", line 19, in resolve_expression
 c = super(Aggregate, self).resolve_expression(query, allow_joins,
 reuse, summarize)
   File "/Users/robin/.virtualenvs/ormweirdness/lib/python3.6/site-
 packages/django/db/models/expressions.py", line 548, in resolve_expression
 c.source_expressions[pos] = arg.resolve_expression(query, allow_joins,
 reuse, summarize, for_save)
   File "/Users/robin/.virtualenvs/ormweirdness/lib/python3.6/site-
 packages/django/db/models/expressions.py", line 411, in resolve_expression
 c.lhs = c.lhs.resolve_expression(query, allow_joins, reuse, summarize,
 for_save)
   File "/Users/robin/.virtualenvs/ormweirdness/lib/python3.6/site-
 packages/django/db/models/expressions.py", line 471, in resolve_expression
 return query.resolve_ref(self.name, allow_joins, reuse, summarize)
   File "/Users/robin/.virtualenvs/ormweirdness/lib/python3.6/site-
 packages/django/db/models/sql/query.py", line 1472, in resolve_ref
 return self.annotation_select[name]
 KeyError: 'multiplier'

 --
 Ran 1 test in 0.004s

 FAILED (errors=1)
 Destroying test database for alias 'default'...

 }}}

 I've found one person that also seemed to have this problem on the django-
 users mailing list: https://groups.google.com/forum/#!topic/django-
 users/SYAGaVuEjHY

 Happens on Django 1.11.7, python3.6. sqlite3 as well as postgres10.

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

-- 
You received this message because you are subscribed

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'"

[Django]

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gene Sem):

 Where error is located:

 WORKING file `django/db/backends/mysql/base.py` line 241  (django 2.0b1):


 {{{
 def init_connection_state(self):
 assignments = []
 if self.features.is_sql_auto_is_null_enabled:
 # SQL_AUTO_IS_NULL controls whether an AUTO_INCREMENT column
 on
 # a recently inserted row will return when the field is tested
 # for NULL. Disabling this brings this aspect of MySQL in line
 # with SQL standards.
 assignments.append('SQL_AUTO_IS_NULL = 0')

 if self.isolation_level:
 assignments.append("TX_ISOLATION = '%s'" %
 self.isolation_level)

 }}}

 DONT WORKING file `django/db/backends/mysql/base.py` line 238 (django2.0
 rc1):


 {{{
 def init_connection_state(self):
 assignments = []
 if self.features.is_sql_auto_is_null_enabled:
 # SQL_AUTO_IS_NULL controls whether an AUTO_INCREMENT column
 on
 # a recently inserted row will return when the field is tested
 # for NULL. Disabling this brings this aspect of MySQL in line
 # with SQL standards.
 assignments.append('SQL_AUTO_IS_NULL = 0')

 if self.isolation_level:
 err->   assignments.append("%s = '%s'" %
 (self.transaction_isolation_variable, self.isolation_level))
 }}}

 

 where `self.transaction_isolation_variable`:


 {{{
   @cached_property
 def transaction_isolation_variable(self):
 return 'tx_isolation' if self.mysql_version < (5, 7, 20) else
 'transaction_isolation'

 }}}

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

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'"

[Django]

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gene Sem):

 The bug exists with MariaDB versions: 10.0.31, 10.0.33 (latest), 10.1.28,
 10.1.29 (latest).

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

Re: [Django] #28801: Outdated translatable text of a contrib.auth literal

[Django]

#28801: Outdated translatable text of a contrib.auth literal
-+-
 Reporter:  Ramiro Morales   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.0
  Internationalization   |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  transifex| Triage Stage:
  makemessages po catalog|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

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


Comment:

 Yes, your explanation is right.
 It might be useful to fetch and include translations before the RC1, but
 as we don't guarantee string freeze before RC1, the "risk" is to have to
 reinclude most translations a second time before final release. And that's
 a problem currently because of the size of the binary .mo files in the
 repository (#23321).

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

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

[Django]

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I'd favour "a", too, unless we find a general-enough use case to
 demonstrate their utility.

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

Re: [Django] #28608: Allow UserCreationForm and UserChangeForm to work with custom user models

[Django]

#28608: Allow UserCreationForm and UserChangeForm to work with custom user 
models
-+-
 Reporter:  Rômulo Collopy   |Owner:  hui shang
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  user, custom user,   | Triage Stage:  Accepted
  auth   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by hui shang):

 * status:  new => assigned
 * needs_better_patch:  1 => 0
 * owner:  nobody => hui shang


Comment:

 Since This ticket is related to
 [https://code.djangoproject.com/ticket/28757  ticket 28757], I made the
 changes for this ticket and ticket 28757 in the same commit.

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