Re: [Django] #897: Bi-Directional ManyToMany in Admin

[Django]

#897: Bi-Directional ManyToMany in Admin
---+
 Reporter:  anonymous  |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  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 mitar):

 The form approach does not work correctly because in the history view of
 the model in admin there are no entries for changed reverse M2M fields.

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

Re: [Django] #25579: Lack of type adaptation in ArrayField querying/lookups

[Django]

#25579: Lack of type adaptation in ArrayField querying/lookups
-+-
 Reporter:  freshquiz|Owner:  freshquiz
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayField query | Triage Stage:  Accepted
  lookup |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by freshquiz:

Old description:

> This commit:
> [https://github.com/django/django/commit/39d95fb6ada99c59d47fa0eae6d3128abafe2d58]
> replaces the `get_prep_value` method with `get_db_prep_value` and I
> believe this causes a regression with regards to querying on an
> ArrayField.
>
> `get_db_prep_value` is never called during querying/lookup, hence the
> array items/values are passed directly to the low-level database Python
> wrappers without first being transformed (from Python objects to SQL-
> friendly parameters).
>
> See this question: [http://stackoverflow.com/questions/33250371
> /arrayfield-class-missing-query-lookup-methods]
>
> Could both the `get_prep_value` and `get_db_prep_value` methods be
> overridden with duplicate/shared logic to overcome this issue?

New description:

 This commit:
 
[https://github.com/django/django/commit/39d95fb6ada99c59d47fa0eae6d3128abafe2d58]
 replaces the `get_prep_value` method with `get_db_prep_value` and I
 believe this causes a regression with regards to querying on an
 ArrayField.

 `get_db_prep_value` is never called during querying/lookup, hence the
 array items/values are passed directly to the low-level database Python
 wrappers without first being transformed (from Python objects to SQL-
 friendly parameters).

 See this question: [http://stackoverflow.com/questions/33250371
 /arrayfield-class-missing-query-lookup-methods]

 Could both the `get_prep_value` and `get_db_prep_value` methods be
 overridden with duplicate/shared logic to overcome this issue?

 Patch pull request: [https://github.com/django/django/pull/6278]

--

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

Re: [Django] #25579: Lack of type adaptation in ArrayField querying/lookups

[Django]

#25579: Lack of type adaptation in ArrayField querying/lookups
-+-
 Reporter:  freshquiz|Owner:  freshquiz
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayField query | Triage Stage:  Accepted
  lookup |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by freshquiz):

 * status:  new => assigned
 * owner:   => freshquiz
 * has_patch:  0 => 1


Comment:

 Thanks @charettes.

 I wasn't sure if linking to the pull request was necessary, because it
 seemed to happen automatically in the details box at the top, but here is
 the link anyway:

 [https://github.com/django/django/pull/6278]

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

Re: [Django] #25579: Lack of type adaptation in ArrayField querying/lookups

[Django]

#25579: Lack of type adaptation in ArrayField querying/lookups
-+-
 Reporter:  freshquiz|Owner:
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayField query | Triage Stage:  Accepted
  lookup |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Please assign this ticket to yourself to prevent parallel work, check
 ''Has Patch'' and preferably link to your PR.

 The only thing you can't do is mark your own patch as ''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/067.108181f2182956389fc52509e14df8e1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #897: Bi-Directional ManyToMany in Admin

[Django]

#897: Bi-Directional ManyToMany in Admin
---+
 Reporter:  anonymous  |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  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 mitar):

 * cc: mmitar@… (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.1ee1e708de27d16241bfd123166c90b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24317: Deprecate field.rel, replace it with real field instances

[Django]

#24317: Deprecate field.rel, replace it with real field instances
-+-
 Reporter:  akaariai |Owner:  auvipy
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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 mitar):

 * cc: mmitar@… (added)


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

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

Re: [Django] #25579: Lack of type adaptation in ArrayField querying/lookups

[Django]

#25579: Lack of type adaptation in ArrayField querying/lookups
-+-
 Reporter:  freshquiz|Owner:
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayField query | Triage Stage:  Accepted
  lookup |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by freshquiz):

 I've created a pull request for this, but I'm not sure if I need to change
 any of the configuration (e.g. "Has patch" and whether I should take
 ownership) for this ticket, or if that's done by the core devs.

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

Re: [Django] #26296: values() after extra() gives incorrect error message

[Django]

#26296: values() after extra() gives incorrect error message
-+-
 Reporter:  vvkuznetsov  |Owner:
 Type:   |  vvkuznetsov
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 The patch causes a regression in another unit test, so I'm not going to
 bother spending more time on this.

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

Re: [Django] #26348: Add a __time lookup for DateTimeField

[Django]

#26348: Add a __time lookup for DateTimeField
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 timgraham):

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

Re: [Django] #26349: A cookie named "?" breaks CSRF

[Django]

#26349: A cookie named "?" breaks CSRF
+--
 Reporter:  eyelidlessness  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  CSRF|  Version:  1.9
 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 timgraham):

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


Comment:

 We use
 
[https://github.com/python/cpython/blob/750ed3ef784a5261f50b1ce146d561c7aefdac67/Lib/http/cookies.py#L458-L478
 cookie parsing from Python] and I believe those are invalid characters for
 a cookie key value. If parsing fails, remaining cookies will be ignored by
 Python's current parsing scheme. There's an open ticket for Python which
 may improve the situation: http://bugs.python.org/issue25228

 Unless you can point to why Django is at fault, I believe this class of
 issue should be directed at Python.

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

Re: [Django] #26349: A cookie named "?" breaks CSRF

[Django]

#26349: A cookie named "?" breaks CSRF
+--
 Reporter:  eyelidlessness  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  CSRF|  Version:  1.9
 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 eyelidlessness):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Any cookie using a double quote also seems to trigger this issue.

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

[Django] #26349: A cookie named "?" breaks CSRF

[Django]

#26349: A cookie named "?" breaks CSRF
+
 Reporter:  eyelidlessness  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  CSRF|Version:  1.9
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Steps to reproduce:

 1. Create a cookie with a question mark in its name.
 2. Perform any request which would CSRF protection.

 Expected result:

 The unrelated cookie would have no impact on CSRF in the request.

 Observed result:

 Request fails with "CSRF cookie not set."

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

[Django] #26348: Add a __time lookup for DateTimeField

[Django]

#26348: Add a __time lookup for DateTimeField
-+-
   Reporter:  charettes  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Now that we've added the `__date` (#9596) lookup I think we should allow
 the same for the time part.

 A good
 
[https://www.reddit.com/r/django/comments/49p8dg/excluding_hours_range_ex_from_215am_to_5am_from_a/
 usage example] would be:

 {{{#!python
 Event.objects.filter(
 datetime__time__range=(start_time, end_time),
 )
 }}}

 To select all activities that occurred in a timezone aware time range.

 Here's an implementation for PostgreSQL and MySQL missing tests:

 {{{#!python
 from django.conf import settings
 from django.db import models
 from django.utils import timezone
 from django.utils.functional import cached_property


 class DateTimeTimeTransform(models.Transform):
 lookup_name = 'time'

 @cached_property
 def output_field(self):
 return models.TimeField()

 def as_mysql(self, compiler, connection):
 lhs, lhs_params = compiler.compile(self.lhs)
 if settings.USE_TZ:
 lhs = "CONVERT_TZ(%s, 'UTC', %%s)" % lhs
 tzname = timezone.get_current_timezone_name()
 lhs_params.append(tzname)
 sql = "TIME(%s)" % lhs
 return sql, lhs_params

 def as_postgresql(self, compiler, connection):
 lhs, lhs_params = compiler.compile(self.lhs)
 if settings.USE_TZ:
 lhs = "%s AT TIME ZONE %%s" % lhs
 tzname = timezone.get_current_timezone_name()
 lhs_params.append(tzname)
 sql = "(%s)::time" % lhs
 return sql, lhs_params

 models.DateTimeField.register_lookup(DateTimeTimeTransform)
 }}}

 We should wait for the datetime expression refactor (#25774) to land
 before proceeding with this patch.

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

Re: [Django] #26337: Translations - No fallback used if requesting english variant

[Django]

#26337: Translations - No fallback used if requesting english variant
-+-
 Reporter:  cristianocca |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  i18n translations| Triage Stage:  Accepted
  english|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cristianocca):

 I think that's good, and will clear any doubt of "Why I am not getting my
 texts translated" when it happens.

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

Re: [Django] #26345: Clarify that RangeFields always return canonical form of ranges

[Django]

#26345: Clarify that RangeFields always return canonical form of ranges
--+
 Reporter:  dbinetti  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.9
 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 dbinetti):

 * Attachment "26345.patch" added.


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

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

Re: [Django] #8936: admin databrowse (read-only view-only permissions)

[Django]

#8936: admin databrowse (read-only view-only permissions)
---+--
 Reporter:  simon  |Owner:  PetrDlouhy
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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
---+--
Changes (by int-ua):

 * cc: serhiy.int@… (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.7b24a56a1ca2226d9d5a4d479b780cd1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17635: Missing ability to cast georaphy to geometry when using GeoDjango and PostgresSQL

[Django]

#17635: Missing ability to cast georaphy to geometry when using GeoDjango and
PostgresSQL
--+
 Reporter:  corentin.chary@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  GIS   |  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 claudep):

 Once #24932 is fixed, we should be able to leverage the `Cast()` database
 function to achieve this.

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

Re: [Django] #24932: Add Cast database function

[Django]

#24932: Add Cast database function
-+-
 Reporter:  Ian-Foote|Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


Comment:

 [https://github.com/django/django/pull/6271 New PR] based on Ian's patch.

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

Re: [Django] #26347: Saving ManyToMany field under race condition causes data loss

[Django]

#26347: Saving ManyToMany field under race condition causes data loss
-+-
 Reporter:  hchargois|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql transaction| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Could you check if you can reproduce with Django 1.9? It might be resolved
 by the [https://docs.djangoproject.com/en/stable/releases/1.9/#related-
 set-direct-assignment related set direct assignment] change.

 If it's fixed in 1.9, I'm not sure if there's much value in patching
 Django 1.8 as I assume this isn't a new issue and I'm not sure if it'd be
 feasible to fix it without an invasive patch.

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

Re: [Django] #25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that differs from map srid

[Django]

#25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that
differs from map srid
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  1.9
 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:"1f035e6283dc06ad9ab719e786944a094c7eb330" 1f035e62]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f035e6283dc06ad9ab719e786944a094c7eb330"
 Fixed #25865 -- Made OSMGeoAdmin require GDAL only if transformation is
 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/068.7db1254c850cd43e877bec90a6979443%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25452: Email validation for domain `gmail.-com` is considered valid

[Django]

#25452: Email validation for domain `gmail.-com` is considered valid
+
 Reporter:  phalt   |Owner:  bak1an
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  1.8
 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 collinanderson):

 Though it gets more complicated when considering Unicode. Unicode needs to
 get normalized to ascii before running through the official regex.

 Here's how chrome does it:
 
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/forms/EmailInputType.cpp

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

[Django] #26347: Saving ManyToMany field under race condition causes data loss

[Django]

#26347: Saving ManyToMany field under race condition causes data loss
--+
 Reporter:  hchargois |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:  mysql
  |  transaction
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I had to investigate mysteriously disappearing contents of some
 ManyToManyFields of some Model. Everyone who had access to the admin site
 assured me that one day the contents were there, and the next day they
 weren't anymore, even though they didn't touch those fields. Of course, we
 had absolutely no custom code to edit those fields, and it looks like they
 didn't lie, nothing showed up in the admin history. I was stumped.

 I found that they were erased whenever someone did a double-click on the
 "Save" button (unintentionally, hopefully).

 It took me some time to really identify the root of the problem...

 Looking at the database log, I found that on each save, even if the field
 is untouched, this happens (a bit simplified):

 {{{
 DELETE * FROM relation_table WHERE from_id = ;
 SELECT * FROM relation_table WHERE from_id =  and to_id in
 (, ,... );
 INSERT INTO relation_table (from_id, to_id) VALUES (,
 ), (, ), ...;
 }}}

 The DELETE then INSERT behavior is visible here:
 
https://github.com/django/django/blob/1.8.11/django/db/models/fields/related.py#L1271

 And the SELECT in between spawns from the manager.add, from this code that
 checks that we only insert what is not already present:
 
https://github.com/django/django/blob/1.8.11/django/db/models/fields/related.py#L1090

 So, yeah, deleting everything, selecting from what we just deleted (that
 should always be nothing, right?) and inserting back the same things is a
 really weird, unoptimized and dangerous way of doing nothing, but since it
 is all in a nice transaction, that should always work, right? Right?

 Well, no. Not with MySQL of course.

 Sometimes, a race condition makes it possible that the SELECT after the
 DELETE does return some old rows that really aren't there anymore. This
 fools the manager.add to think that it has nothing to INSERT since the
 rows are already there. But as soon as the transaction is finished, no
 rows are effectively there anymore.

 This behavior of MySQL is called "consistent read" and is well documented:
 https://dev.mysql.com/doc/refman/5.5/en/innodb-consistent-read.html

 Another bug report that arose due to the same MySQL "feature": #13906
 I'm filing another report because that previous one seems to go nowhere
 and focuses on get_or_create(), whereas I'm showing here that this MySQL
 behavior can also cause very obscure data loss, and is thus IMHO of the
 utmost importance and should be fixed ASAP.

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

Re: [Django] #25415: Make DiscoverRunner run system checks (was: Django 1.8 regression: tests no longer run checks)

[Django]

#25415: Make DiscoverRunner run system checks
---+
 Reporter:  adamchainz |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 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 timgraham):

 * version:  1.8 => master
 * type:  Bug => New feature


Comment:

 As I wrote [https://groups.google.com/d/topic/django-developers/GyuVJ-
 E6Or4/discussion to the mailing list] , I'm fine to proceed with this. We
 need a separate commit to fix the existing errors/warnings in Django's
 test suite, as well as documentation for the change and a mention in the
 release notes.

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

Re: [Django] #25452: Email validation for domain `gmail.-com` is considered valid

[Django]

#25452: Email validation for domain `gmail.-com` is considered valid
+
 Reporter:  phalt   |Owner:  bak1an
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  1.8
 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 collinanderson):

 I think we should try to match the standard html 
 validation. I'd imagine that most uses cases would want to match that. We
 use the regex verbatim from the standard itself:

 https://html.spec.whatwg.org/multipage/forms.html#e-mail-
 state-(type=email)

 If people want to allow things outside of that they could use a custom
 regex.

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

Re: [Django] #25452: Email validation for domain `gmail.-com` is considered valid

[Django]

#25452: Email validation for domain `gmail.-com` is considered valid
+
 Reporter:  phalt   |Owner:  bak1an
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  1.8
 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 timgraham):

 I am open to that if you can get consensus on the DevelopersMailingList on
 a set of limitations that we can document so that we have something to
 point to when we get requests for enhancements. I imagine this policy
 would also include `URLValidator`.

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

Re: [Django] #25452: Email validation for domain `gmail.-com` is considered valid

[Django]

#25452: Email validation for domain `gmail.-com` is considered valid
+
 Reporter:  phalt   |Owner:  bak1an
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  1.8
 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 nedbatchelder):

 Can I respectfully suggest that continuing to tweak this complex regex to
 get asymptotically closer to perfection is not worth it?  Especially to
 fix false positives.  What real-world problem is happening because
 "gmail.-com" is accepted?  "gmail.ccomm" is also accepted, but is just as
 useless as an email address.

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

Re: [Django] #25708: cannot annotate with geometry value

[Django]

#25708: cannot annotate with geometry value
+--
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 Type:  Bug |   Status:  assigned
Component:  GIS |  Version:  1.8
 Severity:  Normal  |   Resolution:
 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 timgraham):

 * needs_better_patch:  0 => 1


Comment:

 After looking at this a bit closer, I see good arguments for both
 solutions. For lack of a better indicator, I'll mark "patch needs
 improvement" until there's a discussion to find consensus on how to move
 this forward.

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

Re: [Django] #25307: Cannot use .annotate with conditional expressions

[Django]

#25307: Cannot use .annotate with conditional expressions
-+-
 Reporter:  jproffitt|Owner:  nobody
 Type:  Bug  |   Status:  new
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:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 There's a failing test on the 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.c83dcabb9d5b0515c4f1e2354973669c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26337: Translations - No fallback used if requesting english variant

[Django]

#26337: Translations - No fallback used if requesting english variant
-+-
 Reporter:  cristianocca |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  i18n translations| Triage Stage:  Accepted
  english|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Thanks, that use case is much more realistic!

 I would suggest to add the following paragraphs under
 https://docs.djangoproject.com/en/1.9/topics/i18n/translation
 /#implementation-notes :
 {{{
 Non-English base language
 -

 Django makes the general assumption that the original strings in a
 translatable
 project are written in English.
 You can choose another language, but you must be aware of certain
 limitations:

 * ``gettext`` only provide two plural forms for the original messages, so
 you
   will need to also provide a translation for the base language to include
 all
   plural forms if the plural rules for the base language are different
 from
   English.

 * When an English variant is activated and English strings are missing,
 the
   fallback language will not be the :setting:`LANGUAGE_CODE` of the
 project,
   but the original strings. For example, an English user visiting a site
 which
   default language is Spanish and original strings are written in Russian
 will
   fallback to Russian, not to Spanish.
 }}}
 Thoughts?

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

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

Re: [Django] #14092: ImageField should allow SVG

[Django]

#14092: ImageField should allow SVG
-+-
 Reporter:  graeme   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 ambivalentno):

 As svg is required more and more often (and sometimes quite unexpectedly),
 I've made a quick workaround (in django-rest-framework context) to have
 PIL-based image validation and minimal svg detection for the same
 FormField:

 https://7webpages.com/blog/how-to-have-svg-allowed-as-an-image-for-django-
 rest-framework/

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

Re: [Django] #26340: Cannot rollback to a savepoint explicitly after an IntegrityError when autocommit is disabled

[Django]

#26340: Cannot rollback to a savepoint explicitly after an IntegrityError when
autocommit is disabled
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (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 tltx):

 Replying to [comment:5 aaugustin]:
 > Thanks for testing!
 >
 > There's a good chance I'll end up doing this or something equivalent. If
 you're patching Django, patch it that way :-)

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

Re: [Django] #26323: TransactionManagementError is raised when autocommit is false

[Django]

#26323: TransactionManagementError is raised when autocommit is false
-+-
 Reporter:  tltx |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 aaugustin):

 * resolution:  wontfix => duplicate


Comment:

 The OP confirmed that #26340 is the same issue. Let's continue the
 discussion over there.

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

Re: [Django] #26340: Cannot rollback to a savepoint explicitly after an IntegrityError when autocommit is disabled

[Django]

#26340: Cannot rollback to a savepoint explicitly after an IntegrityError when
autocommit is disabled
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (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 aaugustin):

 * cc: tltx (added)


Comment:

 Thanks for testing!

 There's a good chance I'll end up doing this or something equivalent. If
 you're patching Django, patch it that way :-)

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

Re: [Django] #26346: Error in makemigrations while changing DateTimeField default value from timezone aware datetime to naive datetime.now()

[Django]

#26346: Error in makemigrations while changing DateTimeField default value from
timezone aware datetime to naive datetime.now()
-+-
 Reporter:  shahzebiam   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  migrations,  | Triage Stage:
  datetimefield migration,   |  Unreviewed
  makemigrations, default date   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Duplicate of #24822

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

[Django] #26346: Error in makemigrations while changing DateTimeField default value from timezone aware datetime to naive datetime.now()

[Django]

#26346: Error in makemigrations while changing DateTimeField default value from
timezone aware datetime to naive datetime.now()
-+-
 Reporter:   |  Owner:  nobody
  shahzebiam |
 Type:  Bug  | Status:  new
Component:   |Version:  1.8
  Migrations |   Keywords:  migrations, datetimefield
 Severity:  Normal   |  migration, makemigrations, default date
 Triage Stage:   |  Has patch:  0
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 I have a DateTimeField in a model in models.py which i have given a
 default value of django.utils.timezone.now(). When i changed the default
 value to datetime.datetime.now() and ran the makemigrations command, it
 gave me an error in autodetector.py

 {{{
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "C:\Python27\lib\site-packages\django\core\management\__init__.py",
 line 354, in execute_from_command_line
 utility.execute()
   File "C:\Python27\lib\site-packages\django\core\management\__init__.py",
 line 346, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "C:\Python27\lib\site-packages\django\core\management\base.py",
 line 394, in run_from_argv
 self.execute(*args, **cmd_options)
   File "C:\Python27\lib\site-packages\django\core\management\base.py",
 line 445, in execute
 output = self.handle(*args, **options)
   File "C:\Python27\lib\site-
 packages\django\core\management\commands\makemigrations.py", line 125, in
 handle
 migration_name=self.migration_name,
   File "C:\Python27\lib\site-
 packages\django\db\migrations\autodetector.py", line 43, in changes
 changes = self._detect_changes(convert_apps, graph)
   File "C:\Python27\lib\site-
 packages\django\db\migrations\autodetector.py", line 186, in
 _detect_changes
 self.generate_altered_fields()
   File "C:\Python27\lib\site-
 packages\django\db\migrations\autodetector.py", line 850, in
 generate_altered_fields
 if old_field_dec != new_field_dec:
 TypeError: can't compare offset-naive and offset-aware datetimes
 }}}

 as far as i know it is trying to compare a timezone aware date with a
 simple datetime which will not be possible for datetime objects.

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

Re: [Django] #26340: Cannot rollback to a savepoint explicitly after an IntegrityError when autocommit is disabled

[Django]

#26340: Cannot rollback to a savepoint explicitly after an IntegrityError when
autocommit is disabled
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (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 tltx):

 "add self.needs_rollback = False in transaction.rollback()" solved my
 problem in  #26323

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