Re: [Django] #11964: Add the ability to use database-level CHECK CONSTRAINTS

[Django]

#11964: Add the ability to use database-level CHECK CONSTRAINTS
-+-
 Reporter:  Matthew Schinckel|Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  check contsraint | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan Hiebert):

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

Re: [Django] #12279: prepare_database_save in add_update_fields makes some custom fields be impossible.

[Django]

#12279: prepare_database_save in add_update_fields makes some custom fields be
impossible.
-+-
 Reporter:  bear330  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
  prepare_database_save, |  Unreviewed
  ObjectField, ClassField|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sebitoelcheater):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 So, how did you handled this wontfix situation? Did you implement a
 working ClassField?

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

[Django] #28502: Select widget doesn't accept non-string as value

[Django]

#28502: Select widget doesn't accept non-string as value
-+-
   Reporter:  Nguyễn |  Owner:  nobody
  Hồng Quân  |
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  1.11
   Severity:  Normal |   Keywords:  widget filter
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I made a model, with `age_bracket` field, which accepts values from
 choices like this:

 {{{#!python
 AGE_BRACKET = (
 # The value in the first column will be saved in Postgres Range field,
 # so the upper boundary is not counted, i.e for (18, 25) range, the
 value 25
 # is not counted.
 ((None, 18), _('Under 18')),
 ((18, 25), _('18 - 24')),
 ((25, 36), _('25 - 35')),
 ((36, 46), _('36 - 45')),
 ((46, 56), _('46 - 55')),
 ((46, 66), _('56 - 65')),
 ((66, None), _('Above 65')),
 )
 }}}

 However, when being rendered as form, all values become empty string. This
 happens since Django 1.11. In Django 1.10, it was OK.
 I found the cause is the widget template ''select_option.html''

 {{{#!django
 {{ widget.label }}
 }}}

 The `stringformat` filter turns every non-string value to empty string.
 My suggestion is that, update  `stringformat` so that it returns
 `str(value)` if value is not a string. Is it right way to do?

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

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

Re: [Django] #28501: django runserver crashes when run as a module

[Django]

#28501: django runserver crashes when run as a module
---+--
 Reporter:  Chris Darko|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Chris Darko):

 * Attachment "traceback.txt" added.

 Traceback for import error

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

[Django] #28501: django runserver crashes when run as a module

[Django]

#28501: django runserver crashes when run as a module
-+
   Reporter:  Chris Darko|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 In the interests of keeping code modular, we do not use `manage.py
 runserver` in our projects. Instead, we use `django-admin runserver`.

 This works well, but if one wants to run python with some flags, using the
 django module, it is insufficient.

 It would be ideal if `python -m django runserver` worked, for this reason.
 Currently, attempting to do so will yield an import error with similar to
 the attached 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/051.df315375a9aaacdbca59d11a43103c8e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28499: makemigrations fails on model with geometry field when the geo database is not the defaul one

[Django]

#28499: makemigrations fails on model with geometry field when the geo database 
is
not the defaul one
+--
 Reporter:  Kaveh   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  1.8
 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 Simon Charette):

 Hello Kaveh,

 Did you reproduce against 1.11 as well? Would it be possible for you to
 provide the full traceback of the `AttributeError`?

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

[Django] #28500: "EOFError: Ran out of input" from Django file cache when file is empty

[Django]

#28500: "EOFError: Ran out of input" from Django file cache when file is empty
---+
   Reporter:  Justin Crown |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (Cache system)  |Version:  1.11
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 When using Django file cache, if a cache file ends up empty for some
 reason (yes, this actually happened in the wild), an `EOFError` is thrown.

 Steps to reproduce:

 Cache must be set to
 `django.core.cache.backends.filebased.FileBasedCache`.

 {{{
 >>> from django.core.cache import cache
 >>> cache.set('testing' 'test')
 }}}

 In a shell

 {{{
 > cache_dir/file_that_got_created.djcache
 }}}

 Back in the REPL

 {{{
 >>> cache.get('testing')
 Traceback (most recent call last):
   File "/usr/local/lib/python3.6/code.py", line 91, in runcode
 exec(code, self.locals)
   File "", line 1, in 
   File "/usr/local/lib/python3.6/site-
 packages/django/core/cache/backends/filebased.py", line 40, in get
 if not self._is_expired(f):
   File "/usr/local/lib/python3.6/site-
 packages/django/core/cache/backends/filebased.py", line 137, in
 _is_expired
 exp = pickle.load(f)
 EOFError: Ran out of input
 }}}

 As to how these files would end up empty to begin with, I would hazard to
 guess that it is caused by a rare race condition in the file moving
 process:

 https://github.com/django/django/blob/master/django/core/files/move.py#L59

 Whereby if this process is interrupted by a system shutdown, the file is
 created in the appropriate location but is empty.

 Desired behavior would be that in this situation, an exception would not
 be thrown. Rather, `None` (or default) would be returned.

 I am planning on working on a patch towards this, but wanted to log the
 ticket first.

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

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

[Django]

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ruben Alves):

 I consider a bug.

 If a user has a form, and on the same page tries to load an image, css, or
 javascript with a wrong URI, the form will never be 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/068.d3ab2e2de1bc602bf8a1343925d9086d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28499: makemigrations fails on model with geometry field when the geo database is not the defaul one

[Django]

#28499: makemigrations fails on model with geometry field when the geo database 
is
not the defaul one
--+
   Reporter:  Kaveh   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  GIS |Version:  1.8
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Create a django app with two databases defined like this:

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql',
 'NAME': 'whatever'
 ...
 },
 'postgres': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'NAME': 'whatever'
 }
 }
 }}}

 and here is the database router:

 {{{
 POSTGRES_APPS = ['app1']


 class PostgresRouter(object):
 def db_for_read(self, model, **hints):
 if model._meta.app_label in POSTGRES_APPS:
 return 'postgres'
 return None

 def db_for_write(self, model, **hints):
 if model._meta.app_label in POSTGRES_APPS:
 return 'postgres'
 return None

 def allow_relation(self, obj1, obj2, **hints):
 if {obj1._meta.app_label,
 obj2._meta.app_label}.issubset(set(POSTGRES_APPS)):
 return True
 return None

 def allow_migrate(self, db, app_label, model_name=None, **hints):
 if db == 'postgres':
 return app_label in POSTGRES_APPS
 else:
 return app_label not in POSTGRES_APPS
 }}}

 Create an app called `app1` and add it to `INSTALLED_APPS`:

 {{{
 class Shapes(models.Model):
 shape = models.GeometryField()
 }}}

 Now if you run `makemigrations`, it throws the following error:
 `AttributeError: 'DatabaseOperations' object has no attribute
 'geo_db_type'`

 Seems like the error is because Django is using the default connection,
 i.e. mysql, for handling the geomtry field in app1, though this app is
 supposed to be part of the gis enabled database, i.e. postgres.

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

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

Re: [Django] #28497: QuerySet.filter() with a sliced QuerySet crashes

[Django]

#28497: QuerySet.filter() with a sliced QuerySet crashes
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * cc: Simon Charette (added)


Comment:

 We should try to error out with a more appropriate message but I don't
 think we ever officially supported passing a queryset to an `__exact`
 lookup. I vaguely remember a ticket about it but I can't find it anymore.

 I think you should be using an `__in` lookup instead as your query will
 fail with `more than one row returned by a subquery used as an expression`
 as soon as the table backing up your ` Skill` model has more than two
 rows.

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

Re: [Django] #28498: Add cx_Oracle 6 support

[Django]

#28498: Add cx_Oracle 6 support
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  cx_Oracle oracle | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #28073: RemoveField.state_forwards() crashes with AttributeError: 'NoneType' object has no attribute 'is_relation'

[Django]

#28073: RemoveField.state_forwards() crashes with AttributeError: 'NoneType' 
object
has no attribute 'is_relation'
-+
 Reporter:  Logan Gunthorpe  |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
-+

Comment (by Python Force):

 I cannot because it took me 2 days to find out what it was and now it is
 fixed. Problem was that the migration with the missing field in the
 database based on that function was coming empty and you calling a method
 on that which is throwing an error.

 As Logan said "Seeing as the comment above implies that old_field is None
 or ... would be a valid solution I don't see why you wouldn't just put
 that in."

 I have explained everything above in details that is a simple project and
 it happened precisely just like that. I am not sure how better I can
 describe it. I am not sure why you have changed that migration function if
 this one is working well...in 1.10.7.

 {{{
 def state_forwards(self, app_label, state):
  new_fields = []
  for name, instance in state.models[app_label,
 self.model_name_lower].fields:
  if name != self.name:
  new_fields.append((name, instance))
  state.models[app_label, self.model_name_lower].fields = new_fields
  state.reload_model(app_label, self.model_name_lower)
 }}}

 I know 1.11 is a new version but I do not think it would crash the system
 anyway - This

 {{{
 old_field = None
 }}}

 is causing the error. And as a good practice and good software engineering
 if it is None why you did not even put there

 {{{
 try:
 except
 }}}

 at least. Logan and I gave you a hint, and it has happened to 2 people
 already within 3 months, so something must be going on in 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/065.7663a1f205af4b9050cfe1036e14c581%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28495: GDAL Feature.fields should be a list of strs rather than bytestrings

[Django]

#28495: GDAL Feature.fields should be a list of strs rather than bytestrings
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  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 Claude Paroz ):

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


Comment:

 In [changeset:"546412e6731e5e31b8450c35e3dae8ec26bc008c" 546412e]:
 {{{
 #!CommitTicketReference repository=""
 revision="546412e6731e5e31b8450c35e3dae8ec26bc008c"
 Fixed #28495 -- Converted GDAL Feature.fields to strings
 }}}

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

Re: [Django] #25937: Failure when using expressions.DateTime on NULL values and aggregating

[Django]

#25937: Failure when using expressions.DateTime on NULL values and aggregating
-+-
 Reporter:  Thomas Recouvreux|Owner:  Cheryl
 |  Yang
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  aggregate timezone   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aaron McMillin):

 Here's a possible workaround for the failing case:

 {{{
 Potato.objects.annotate(
 time=Coalesce(
 DateTime('removed', 'month', timezone.UTC()),
 Value(datetime.min),
 ).values('time').annotate(c=Count('pk'))
 }}}

 This replaces the NULL times with an easy to spot sentinel. if you were
 already using `datetime.min`, you'll have to come up with something else.

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

Re: [Django] #28498: Add cx_Oracle 6 support (was: Added cx_Oracle 6 support.)

[Django]

#28498: Add cx_Oracle 6 support
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  cx_Oracle oracle | 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):

 * type:  Uncategorized => Cleanup/optimization
 * 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/065.fbec013c514f8ed850c0ee5d6f6e5774%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28498: Added cx_Oracle 6 support.

[Django]

#28498: Added cx_Oracle 6 support.
-+-
   Reporter:  felixxm|  Owner:  felixxm
   Type: | Status:  assigned
  Uncategorized  |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Release|   Keywords:  cx_Oracle oracle
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 cx_Oracle 6 causes a tests failures due to this change:

 ''Prevent closing the connection when there are any open statements or
 LOBs and add new error “DPI-1054: connection cannot be closed when open
 statements or LOBs exist” when this situation is detected; this is needed
 to prevent crashes under certain conditions when statements or LOBs are
 being acted upon while at the same time (in another thread) a connection
 is being closed; it also prevents leaks of statements and LOBs when a
 connection is returned to a session pool.'' (see cx_Oracle [http://cx-
 oracle.readthedocs.io/en/latest/releasenotes.html#version-6-0-august-2017
 release notes]).

 Sample exception:
 {{{
 Traceback (most recent call last):
   File "./runtests.py", line 478, in 
 options.exclude_tags,
   File "./runtests.py", line 286, in django_tests
 extra_tests=extra_tests,
   File "/home/jenkins/workspace/django-oracle-
 master/database/oracle12/label/trusty/python/python3.6/django/test/runner.py",
 line 601, in run_tests
 old_config = self.setup_databases()
   File "/home/jenkins/workspace/django-oracle-
 master/database/oracle12/label/trusty/python/python3.6/django/test/runner.py",
 line 548, in setup_databases
 self.parallel, **kwargs
   File "/home/jenkins/workspace/django-oracle-
 master/database/oracle12/label/trusty/python/python3.6/django/test/utils.py",
 line 176, in setup_databases
 serialize=connection.settings_dict.get('TEST', {}).get('SERIALIZE',
 True),
   File "/home/jenkins/workspace/django-oracle-
 
master/database/oracle12/label/trusty/python/python3.6/django/db/backends/base/creation.py",
 line 54, in create_test_db
 self._create_test_db(verbosity, autoclobber, keepdb)
   File "/home/jenkins/workspace/django-oracle-
 
master/database/oracle12/label/trusty/python/python3.6/django/db/backends/oracle/creation.py",
 line 100, in _create_test_db
 self._maindb_connection.close()  # done with main user -- test user
 and tablespaces created
   File "/home/jenkins/workspace/django-oracle-
 
master/database/oracle12/label/trusty/python/python3.6/django/db/backends/base/base.py",
 line 281, in close
 self._close()
   File "/home/jenkins/workspace/django-oracle-
 
master/database/oracle12/label/trusty/python/python3.6/django/db/backends/base/base.py",
 line 243, in _close
 return self.connection.close()
   File "/home/jenkins/workspace/django-oracle-
 master/database/oracle12/label/trusty/python/python3.6/django/db/utils.py",
 line 89, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/home/jenkins/workspace/django-oracle-
 
master/database/oracle12/label/trusty/python/python3.6/django/db/backends/base/base.py",
 line 243, in _close
 return self.connection.close()
 django.db.utils.DatabaseError: DPI-1054: connection cannot be closed when
 open statements or LOBs exist}}}

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

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

Re: [Django] #28497: QuerySet.filter() with a sliced QuerySet crashes (was: filtering with non-values QuerySet crashes)

[Django]

#28497: QuerySet.filter() with a sliced QuerySet crashes
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * version:  1.11 => master
 * severity:  Normal => Release blocker
 * 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/068.9cb9ca8fe53587ecbe17fb4331e27314%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28154: Infinite loop in collectstatic with broken symlinks

[Django]

#28154: Infinite loop in collectstatic with broken symlinks
-+
 Reporter:  Matthew Somerville   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  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
-+

Comment (by Tim Graham):

 Which commit fixed it? Most likely a fix wouldn't qualify for a backport
 based on our [https://docs.djangoproject.com/en/dev/internals/release-
 process/#supported-versions supported versions policy].

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

Re: [Django] #8936: Add view (read-only) permission to admin

[Django]

#8936: Add view (read-only) permission to admin
---+
 Reporter:  simon  |Owner:  Olivier
 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 Jeppe Vesterbæk):

 * cc: Jeppe Vesterbæk (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.0d66a40c33927c312b570ee14e771449%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

[Django]

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by KwonHan Bae):

 so it's not a bug?
 I think if it a bug we can make another explicit ticket

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

[Django] #28497: filtering with non-values QuerySet crashes

[Django]

#28497: filtering with non-values QuerySet crashes
-+-
   Reporter:  Sergey |  Owner:  nobody
  Fedoseev   |
   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  |
-+-
 {{{
 PersonSkill.objects.filter(skill=Skill.objects.all()[:1])

 ProgrammingError: ОШИБКА:  подзапрос должен вернуть только один столбец
 (subquery should return single column)
 LINE 1: ...nskill" WHERE "test_app_personskill"."skill_id" = (SELECT "t...
 }}}


 Introduced in ec50937bcbe160e658ef881021402e156beb0eaf.

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

Re: [Django] #28154: Infinite loop in collectstatic with broken symlinks

[Django]

#28154: Infinite loop in collectstatic with broken symlinks
-+
 Reporter:  Matthew Somerville   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  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
-+

Comment (by KwonHan Bae):

 I think its fixed in master branch.
 should we backport to 11.x ?

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