date:20170428

Re: [Django] #28105: BaseGeometryWidget.get_context() crashes if attrs contains the name of an existing key

2017-04-28 Thread Django

#28105: BaseGeometryWidget.get_context() crashes if attrs contains the name of 
an
existing key
-+
 Reporter:  Dylan Verheul|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  gis, forms, widgets  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Dylan Verheul):

 * owner:  Dylan Verheul => (none)
 * status:  assigned => new
 * easy:  0 => 1


Comment:

 The test suite keeps getting stuck on my Mac. Seems like this is easy
 pickings so I'll hope someone else picks it up.

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

Re: [Django] #28107: Can't perform annotation on related table when relation between tables not on primary key

2017-04-28 Thread Django

Comment (by powderflask):

It occurs to me that if there were some way to force values into the
group-by clause, that would serve as a reasonable workaround, given this
is bound to be a fairly rare use-case.
I did read some hacks that did this in 1.8, but it looks like
query.group_by is now a boolean rather than a list of fields... was
pretty ugly anyhow.

But I'm not missing something more obvious here am I -- like an extra()
clause or something that could force the offending aggregate fields into
the group_by clause?

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

Re: [Django] #28107: Can't perform annotation on related table when relation between tables not on primary key

2017-04-28 Thread Django

#28107: Can't perform annotation on related table when relation between tables 
not
on primary key
-+-
 Reporter:  powderflask  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by powderflask):

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


Comment:

 OK - that's got it.  Yep -- this issues occurs when at least one of the
 models in the aggregation query is un-managed and backed by a DB view
 rather than a table.

 Attached is a zip of a simple django app that runs in a default django
 container,  demonstrates the issue:

 1) Demonstrate these weird relations work with models backed by DB tables:
  -  {{{ INSTALLED_APPS = [ 'issue28107.apps.Issue28107Config', ... ] }}}
  - configure / create postgre DB,
  - manage.py migrate
  - run the unit-test -- it should pass

 2) Replace table with view (created by migrations)
   - in models.py, remove 2 comments from Treatment.Meta:
 {{{
 managed = False
 db_table = 'issue28107_treatment_vw'

 }}}
  - re-run unit-test -- it should fail:
 {{{ column "issue28107_treatment_vw.globalid" must appear in the GROUP BY
 clause or be used in an aggregate function }}}

 This is a backwards-compatibility issue -- this worked at least up to
 django1.8

 I have no idea where to begin with this in terms of suggesting a patch --
 any pointers?
 thank you for the quick reply and suggestions -- awesome.

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

Re: [Django] #28107: Can't perform annotation on related table when relation between tables not on primary key

2017-04-28 Thread Django

#28107: Can't perform annotation on related table when relation between tables 
not
on primary key
-+-
 Reporter:  powderflask  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by powderflask):

 * Attachment "issue28107.zip" added.

 small django app with models, migrations, and tests that illustrate the
 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/069.40dcb932e934d9e0873e6d4d5a1d88d1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28153: patch: it's now easier to populate data in test databases that run code in parallel (was: patch: it's now easier to populate data databases in test databases that run code in para

2017-04-28 Thread Django

#28153: patch: it's now easier to populate data in test databases that run code 
in
parallel
---+--
 Reporter:  Marcos Diez|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

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

Re: [Django] #28153: patch: it's now easier to populate data databases in test databases that run code in parallel

2017-04-28 Thread Django

#28153: patch: it's now easier to populate data databases in test databases that
run code in parallel
---+--
 Reporter:  Marcos Diez|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Marcos Diez:

Old description:

> Although Django makes very easy for one to extend `
> django.test.runner.DiscoverRunner ` , it's ` setup_databases() ` does too
> much.
>
> Currently, it
>
> - creates all the test databases (for single thread unit tests)
> - duplicates all the test databases (in case of parallel unit tests)
>
> In case I am running not running tests in parallel, I can just populate
> the DB after running unit tests without any issues.
>
> But if I care about my time and want to run tests in parallel, I can
> either:
>
> a) populate my data after setup_databases() is executed, once for each
> thread of the parallel tests, which is slow
> b) get my hands dirty and reimplement ` setup_databases() `
>
> I propose (and I am sending the code to do so) a better solution. We just
> have to break `setup_databases()` in 3 functions:
>
> `DiscoverRunner.prepare_databases() `
> `DiscoverRunner.populate_databases() # noop by default `
> `DiscoverRunner.duplicate_databases_if_necessary()`
>

> The idea is quite simple: in order to be backward compatible, `
> setup_databases() `, will still exist but only call three functions above
> in that order.
>
> The first function will create all the test databases necessary for non
> parallel tests to run.
>
> ` populate_databases() `, which should be a no op, can be overwritten by
> the user who  extends ` django.test.runner.DiscoverRunner ` so his/her
> data can be populated
>
> Afterwards, all the test DBs are copied as many times as necessary in
> case parallel tests are run via `
> DiscoverRunner.duplicate_databases_if_necessary() `
>

> I believe this change on Django will have no downside, will be backward
> compatible and help people who needs to populate real data on the DB for
> their tests.

New description:

 Although Django makes very easy for one to extend `
 django.test.runner.DiscoverRunner ` , it's ` setup_databases() ` does too
 much.

 Currently, it

 - creates all the test databases (for single thread unit tests)
 - duplicates all the test databases (in case of parallel unit tests)

 In case I am running not running tests in parallel, I can just populate
 the DB after running unit tests without any issues.

 But if I care about my time and want to run tests in parallel, I can
 either:

 a) populate my data after setup_databases() is executed, once for each
 thread of the parallel tests, which is slow
 b) get my hands dirty and reimplement ` setup_databases() `

 I propose (and I am sending the code to do so) a better solution. We just
 have to break `setup_databases()` in 3 functions:

 `DiscoverRunner.prepare_databases() `
 `DiscoverRunner.populate_databases() # noop by default `
 `DiscoverRunner.duplicate_databases_if_necessary()`


 The idea is quite simple: in order to be backward compatible, `
 setup_databases() `, will still exist but only call three functions above
 in that order.

 The first function will create all the test databases necessary for non
 parallel tests to run.

 ` populate_databases() `, which should be a no op, can be overwritten by
 the user who  extends ` django.test.runner.DiscoverRunner ` so his/her
 data can be populated

 Afterwards, all the test DBs are copied as many times as necessary in case
 parallel tests are run via `
 DiscoverRunner.duplicate_databases_if_necessary() `


 I believe this change on Django will have no downside, will be backward
 compatible and help people who needs to populate real data on the DB for
 their tests.


 The PR with the changes for this to work is available here:
 https://github.com/django/django/pull/8437

--

--
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

[Django] #28153: patch: it's now easier to populate data databases in test databases that run code in parallel

2017-04-28 Thread Django

#28153: patch: it's now easier to populate data databases in test databases that
run code in parallel
-+
   Reporter:  Marcos Diez|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Although Django makes very easy for one to extend `
 django.test.runner.DiscoverRunner ` , it's ` setup_databases() ` does too
 much.

 Currently, it

 - creates all the test databases (for single thread unit tests)
 - duplicates all the test databases (in case of parallel unit tests)

 In case I am running not running tests in parallel, I can just populate
 the DB after running unit tests without any issues.

 But if I care about my time and want to run tests in parallel, I can
 either:

 a) populate my data after setup_databases() is executed, once for each
 thread of the parallel tests, which is slow
 b) get my hands dirty and reimplement ` setup_databases() `

 I propose (and I am sending the code to do so) a better solution. We just
 have to break `setup_databases()` in 3 functions:

 `DiscoverRunner.prepare_databases() `
 `DiscoverRunner.populate_databases() # noop by default `
 `DiscoverRunner.duplicate_databases_if_necessary()`


 The idea is quite simple: in order to be backward compatible, `
 setup_databases() `, will still exist but only call three functions above
 in that order.

 The first function will create all the test databases necessary for non
 parallel tests to run.

 ` populate_databases() `, which should be a no op, can be overwritten by
 the user who  extends ` django.test.runner.DiscoverRunner ` so his/her
 data can be populated

 Afterwards, all the test DBs are copied as many times as necessary in case
 parallel tests are run via `
 DiscoverRunner.duplicate_databases_if_necessary() `


 I believe this change on Django will have no downside, will be backward
 compatible and help people who needs to populate real data on the DB for
 their tests.

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

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

Re: [Django] #28152: Change SetSerializer to serialize to set literals

2017-04-28 Thread Django

#28152: Change SetSerializer to serialize to set literals
-+-
 Reporter:  Jon Dufresne |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne):

 * status:  new => assigned
 * owner:  nobody => Jon Dufresne
 * has_patch:  0 => 1


Comment:

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

[Django] #28152: Change SetSerializer to serialize to set literals

2017-04-28 Thread Django

#28152: Change SetSerializer to serialize to set literals
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Migrations|Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 While looking for all code that could be converted to set literals and set
 comprehension, it was noticed that the migration's `SetSerializer` does
 not use set literals. If we're to convert all internal code to user set
 literals, the auto generated code should follow the same convention.

 Idea originally discussed in [https://github.com/django/django/pull/8432
 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/052.4a67b8300f61dc7cbb43c4ac1070b0c3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

2017-04-28 Thread Django

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  Alexander Artemenko  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |
  subclass   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rgangopadhya):

 To handle pre_save and all other signals, I took the approach of sending
 all signals to the parent model when triggered by child models:


 {{{
 from django.db import models
 from django.db.models.signals import (
 pre_save,
 post_save,
 pre_delete,
 post_delete,
 m2m_changed,
 )

 class A(models.Model): pass

 class B(A):
 class Meta:
 proxy = True

 signals = [
 pre_save,
 post_save,
 pre_delete,
 post_delete,
 m2m_changed,
 ]

 def make_sender_fn(model, signal):

 def sender_fn(sender, **kwargs):
 # signal send method passes itself
 # as a signal kwarg to its receivers
 kwargs.pop('signal')
 signal.send(sender=model, **kwargs)

 return sender_fn

 def connect_all_signals(from_model, to_model):
 # connecting signals from one model to another
 # is useful when from_model inherits from to_model
 # and hence should take on all behavior from the
 # parent model
 # Django does not send signals for parent model
 # when child is triggered
 # https://code.djangoproject.com/ticket/9318#no1
 for signal in signals:
 signal.connect(
 make_sender_fn(to_model, signal),
 sender=from_model,
 weak=False,
 )

 connect_all_signals(B, A)
 }}}

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

Re: [Django] #28107: Can't perform annotation on related table when relation between tables not on primary key

2017-04-28 Thread Django

#28107: Can't perform annotation on related table when relation between tables 
not
on primary key
-+-
 Reporter:  powderflask  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  QuerySet.extra   | 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):

 powderflask, if this happens to be the source of the issue and you are
 using un-managed models (`_meta.managed = False`) maybe we could branch on
 that to prevent the optimization.

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

Re: [Django] #28107: Can't perform annotation on related table when relation between tables not on primary key

2017-04-28 Thread Django

#28107: Can't perform annotation on related table when relation between tables 
not
on primary key
-+-
 Reporter:  powderflask  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by powderflask):

 This may have to do with one of the original models drawing data from a
 View - found this:
 " The feature of Postgres to be able to use the primary key of a table
 with GROUP BY and not need to add the other columns of that table in the
 GROUP BY clause is relatively new and works only for base tables. The
 optimizer is not (yet?) clever enough to identify primary keys for views,
 ctes or derived tables."
 https://dba.stackexchange.com/questions/88988/postgres-error-column-must-
 appear-in-the-group-by-clause-or-be-used-in-an-aggre

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

Re: [Django] #28099: Reuse of UpdateQuery breaks complex delete updates

2017-04-28 Thread Django

#28099: Reuse of UpdateQuery breaks complex delete updates
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-

Comment (by Simon Charette):

 Milosu, are you able to reproduce without a custom `on_delete` handler?

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

Re: [Django] #28151: '__startswith' issue on Oracle 10G

2017-04-28 Thread Django

#28151: '__startswith' issue on Oracle 10G
-+-
 Reporter:  Daniel Klass |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle, ORM, | Triage Stage:
  Queryset, startswith   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniel Klass):

 I don't have access to other Oracle instances, so I'll close this issue.
 Thank you for your help!

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

Re: [Django] #28151: '__startswith' issue on Oracle 10G

2017-04-28 Thread Django

#28151: '__startswith' issue on Oracle 10G
-+-
 Reporter:  Daniel Klass |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Oracle, ORM, | Triage Stage:
  Queryset, startswith   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Daniel Klass):

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


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

Re: [Django] #28099: Reuse of UpdateQuery breaks complex delete updates

2017-04-28 Thread Django

#28099: Reuse of UpdateQuery breaks complex delete updates
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 milosu):

 * Attachment "delete_on_update_bug_update.diff" 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/064.022e61b7cfb11d187b9fbcf777e0c91a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28148: Document addition of validate_image_file_extension() as a backwards incompatible change for ImageField (was: behaviour change on ImageField because of django.core.validators.valid

2017-04-28 Thread Django

#28148: Document addition of validate_image_file_extension() as a backwards
incompatible change for ImageField
--+
 Reporter:  rm_   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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:  1 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Forms => Documentation
 * easy:  0 => 1
 * 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/061.1f2023ed14198c6edafa4a18fa9213d6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28138: Use cursor output type handler on Oracle.

2017-04-28 Thread Django

#28138: Use cursor output type handler on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle cx_Oracle | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"f3427ccb25806bb062becad0d6a0904930b36635" f3427ccb]:
 {{{
 #!CommitTicketReference repository=""
 revision="f3427ccb25806bb062becad0d6a0904930b36635"
 Refs #28138 -- Added release notes for
 d52577b62b3138674807ac74251fab7faed48331.
 }}}

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

Re: [Django] #28150: Behavour of django.utils.text.slugify is not consistent between Python 2 and 3 when passed a tuple (was: Behavour of django.utils.text.slugify is not consistent)

2017-04-28 Thread Django

#28150: Behavour of django.utils.text.slugify is not consistent between Python 2
and 3 when passed a tuple
-+-
Reporter: Marcos Diez |Owner: nobody
Type: Bug | Status: closed
Component: Utilities| Version: 1.11
Severity: Normal | Resolution: wontfix
Keywords: slugify unicode | Triage Stage:
enconding | Unreviewed
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-
Changes (by Tim Graham):

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

Comment:

I would call that improper usage since `slugify()` expects a string, not a
tuple. In any case, since the master branch doesn't support Python 2 and
it doesn't look like a fix qualifies for a backport based on our
[https://docs.djangoproject.com/en/dev/internals/release-process
/#supported-versions supported versions policy], I think we can close it
as wontfix.

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

Re: [Django] #14149: LIKE clauses fail in Oracle 9.2.0.7

2017-04-28 Thread Django

#14149: LIKE clauses fail in Oracle 9.2.0.7
-+-
 Reporter:  JirkaV   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  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 Tim Graham):

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


Old description:

> Hi,
>
>   I've recently started using Oracle backend, connecting to a database I
> don't own or operate. I started seeing behaviour described in #5985
> (DatabaseError: ORA-01425: escape character must be character string of
> length 1), fixed in r7412. Since I was hitting an issue that's been
> apparently fixed, I started digging in history and found that the fix was
> reverted in r12293 (related ticket: #11017). The fact that it might
> reintroduce the bug is actually mentioned in the ticket.
>
>   I'm happy monkeypatching my Oracle base.py as I may as well be the only
> person suffering from this issue these days. Mentioning it here mostly
> for the record, if someone searches for it in future. I'm also happy to
> help testing any suggested solutions if someone has an idea that would
> fix #5985 without breaking #11017 again.
>
>  For the record, the database I'm connecting to is 9.2.0.7 (I know, old).
>
>   Cheers
>
> Jirka

New description:

 I've recently started using Oracle backend, connecting to a database I
 don't own or operate. I started seeing behaviour described in #5985
 (DatabaseError: ORA-01425: escape character must be character string of
 length 1), fixed in r7412. Since I was hitting an issue that's been
 apparently fixed, I started digging in history and found that the fix was
 reverted in r12293 (related ticket: #11017). The fact that it might
 reintroduce the bug is actually mentioned in the ticket.

 I'm happy monkeypatching my Oracle base.py as I may as well be the only
 person suffering from this issue these days. Mentioning it here mostly for
 the record, if someone searches for it in future. I'm also happy to help
 testing any suggested solutions if someone has an idea that would fix
 #5985 without breaking #11017 again.

 For the record, the database I'm connecting to is 9.2.0.7 (I know, old).

--

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

Re: [Django] #28151: '__startswith' issue on Oracle 10G

2017-04-28 Thread Django

#28151: '__startswith' issue on Oracle 10G
-+-
 Reporter:  Daniel Klass |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle, ORM, | Triage Stage:
  Queryset, startswith   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Is the issue specific to Oracle 10? Django 1.7 is the last version of
 Django to support that version. (see the
 [https://docs.djangoproject.com/en/dev/releases/1.8/#support-for-oracle-
 versions-older-than-11-1Django 1.8 release note])

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

Re: [Django] #28126: Add GistIndex Model Index

2017-04-28 Thread Django

#28126: Add GistIndex Model Index
+
 Reporter:  Flavio Curella  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  GIS |  Version:  1.11
 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 Mads Jensen):

 * stage:  Ready for checkin => Accepted


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

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

Re: [Django] #28149: QuerySet model fields comparison

2017-04-28 Thread Django

#28149: QuerySet model fields comparison
-+-
 Reporter:  Vladislav Lutkov |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (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 Simon Charette):

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


Comment:

 Duplicate of #5763.

 The linked ticket provides more context about the 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/068.3e440b016e1e0458a4a8fbc0e9351a08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28138: Use cursor output type handler on Oracle.

2017-04-28 Thread Django

#28138: Use cursor output type handler on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle cx_Oracle | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"12a3032df0d77a782281f22aae82f7083a928225" 12a3032d]:
 {{{
 #!CommitTicketReference repository=""
 revision="12a3032df0d77a782281f22aae82f7083a928225"
 [1.11.x] Refs #28138 -- Added release notes for
 d52577b62b3138674807ac74251fab7faed48331.
 }}}

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

Re: [Django] #28138: Use cursor output type handler on Oracle.

2017-04-28 Thread Django

#28138: Use cursor output type handler on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle cx_Oracle | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d52577b62b3138674807ac74251fab7faed48331" d52577b]:
 {{{
 #!CommitTicketReference repository=""
 revision="d52577b62b3138674807ac74251fab7faed48331"
 [1.11.x] Fixed #28138 -- Used output type handler instead of
 numbersAsStrings on Oracle cursor.

 Thanks Tim Graham for the review.

 Backport of 946775227c56d7a4c6a43343b2e88af837f99f49 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/065.3b2d9b0aa03c1d2281ba4c277f05c346%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28123: django.utils.html.smart_urlquote() is incorrectly parsing the query string

2017-04-28 Thread Django

#28123: django.utils.html.smart_urlquote() is incorrectly parsing the query 
string
+--
 Reporter:  Denis Pechenev  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Uncategorized   |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  smart_urlquote  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Tim Graham):

 As far as I can tell, Python 3 isn't affected. Since the master branch
 doesn't support Python 2 and I don't think this issue qualifies for a
 backport based on our [https://docs.djangoproject.com/en/dev/internals
 /release-process/#supported-versions supported versions policy], I think
 we can close it as wontfix.

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

Re: [Django] #28138: Use cursor output type handler on Oracle.

2017-04-28 Thread Django

#28138: Use cursor output type handler on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle cx_Oracle | 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 GitHub ):

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


Comment:

 In [changeset:"946775227c56d7a4c6a43343b2e88af837f99f49" 9467752]:
 {{{
 #!CommitTicketReference repository=""
 revision="946775227c56d7a4c6a43343b2e88af837f99f49"
 Fixed #28138 -- Used output type handler instead of numbersAsStrings on
 Oracle cursor.

 Thanks Tim Graham for the review.
 }}}

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

Re: [Django] #28143: CSRF token fails when Debug is disabled and a custom view is used for handler404

2017-04-28 Thread Django

Comment (by antigaprime):

Replying to [comment:1 Tim Graham]:
> Can you explain why Django is at fault, or are you looking for help to
debug your application? In the latter case, you should
TicketClosingReasons/UseSupportChannels rather than this ticket tracker.

Well can you explain the behavior? Why would the CSRF fail for the admin
panel, considering that the token is rotated after login, not before, but
not for post requests in "my application"? The admin panel is not "my
application", it's a default component of Django. If the behavior is
erratic, it might as well be a bug, but if a Django developer comes on and
states that this is "expected behavior", then there should be an
explanation.

Help is always welcome, but I've already solved it. Adding the
`@requires_csrf_token` decorator solves it, but I still thought I'd create
the ticket, because there is no documentation regarding having to add this
decorator, and, I can't explain the behavior regarding switching from
using csrf in session and in cookies, and it randomly validating when
refreshing before logging in.

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

[Django] #28151: '__startswith' issue on Oracle 10G

2017-04-28 Thread Django

#28151: '__startswith' issue on Oracle 10G
-+-
   Reporter:  Daniel |  Owner:  nobody
  Klass  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|   Keywords:  Oracle, ORM,
   Severity:  Normal |  Queryset, startswith
   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 string that contains literal underscores that is being used in a
 '__startswith' query. I get

 {{{
 ORA-01424: missing or illegal character following the escape character
 }}}

 The query looks as so:

 {{{
 SELECT ... FROM... WHERE LIKE TRANSLATE(Some\_thing\_here\_now% USING
 NCHAR_CS) ESCAPE TRANSLATE(\ USING NCHAR_CS)
  }}}

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

Re: [Django] #28099: Reuse of UpdateQuery breaks complex delete updates

2017-04-28 Thread Django

#28099: Reuse of UpdateQuery breaks complex delete updates
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 milosu):

 * Attachment "delete_on_update_bug_update.diff" 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/064.6a4d84b5deff222bbbde69353c02aeee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28099: Reuse of UpdateQuery breaks complex delete updates

2017-04-28 Thread Django

#28099: Reuse of UpdateQuery breaks complex delete updates
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-

Comment (by milosu):

 Hi, guys, I'm attaching new simplified patch. Fails against Django 1.11 on
 Windows in my test setup. Even against SQL Lite.

 Clear enough now?

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

Re: [Django] #28130: Formset validate_min validation ignores unchanged forms

2017-04-28 Thread Django

#28130: Formset validate_min validation ignores unchanged forms
-+-
 Reporter:  Jim Ouwerkerk|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  formsets | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"e93135b067c4f2bfe423e605bdfe0786eaecaef2" e93135b0]:
 {{{
 #!CommitTicketReference repository=""
 revision="e93135b067c4f2bfe423e605bdfe0786eaecaef2"
 [1.11.x] Fixed #28130 -- Fixed formset min_num validation with initial,
 unchanged forms.

 Regression in f5c6295797b8332134fd89e0209a18a1d1d45e0c.

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

Re: [Django] #28147: Saving parent object after setting on child leads to unexpected data loss

2017-04-28 Thread Django

#28147: Saving parent object after setting on child leads to unexpected data 
loss
-+-
 Reporter:  Erwin Junge  |Owner:  Erwin
 |  Junge
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Erwin Junge):

 * status:  new => assigned
 * owner:  nobody => Erwin Junge
 * version:  1.11 => 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.5905661a92268d9e64b15c3860662f7f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28149: QuerySet model fields comparison (was: QuerySet model fields comparsion)

2017-04-28 Thread Django

#28149: QuerySet model fields comparison
--+--
 Reporter:  Vladislav Lutkov  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Uncategorized |  Version:
 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
--+--

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

Re: [Django] #28150: Behavour of django.utils.text.slugify is not consistent

2017-04-28 Thread Django

#28150: Behavour of django.utils.text.slugify is not consistent
-+-
 Reporter:  Marcos Diez  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  slugify unicode  | Triage Stage:
  enconding  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Marcos Diez:

Old description:

> After hours of debugging, I realized the behavior of
> django.utils.text.slugify is not consistent.
>
> On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)
>
> {{{
> from django.utils.text import slugify
>
> original_value = ('test trial', )
> slug = slugify(original_value) # returns "test-trial"
> }}}
>
> but on Python 2.7.12
>
> {{{
> from __future__ return unicode_literals
>
> from django.utils.text import slugify
>
> original_value = ('test trial', )
> slug = slugify(original_value) # returns "utest-trial"
> }}}
>
> This is serious and inconsistent.
> Fixing it is not trivial either because it may cause backwards
> incompatibility.
>
> If I was in charge I would either:
> - Do nothing since python 2.7 will be deprecated
> - Deprecate slugify and create slugify2 which is not affected by this bug
>

>
> Thanks for your time,
> Marcos Diez

New description:

 After hours of debugging, I realized the behavior of
 django.utils.text.slugify is not consistent.

 On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)

 {{{
 from django.utils.text import slugify


 original_value = ('test trial', )
 slug = slugify(original_value)
 print(slug) # returns "test-trial"

 }}}

 but on Python 2.7.12

 {{{
 from __future__ return unicode_literals

 from django.utils.text import slugify


 original_value = ('test trial', )
 slug = slugify(original_value)
 print(slug) # returns "utest-trial"

 }}}

 This is serious and inconsistent.
 Fixing it is not trivial either because it may cause backwards
 incompatibility.

 If I was in charge I would either:
 - Do nothing since python 2.7 will be deprecated
 - Deprecate slugify and create slugify2 which is not affected by this bug



 Thanks for your time,
 Marcos Diez

--

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

Re: [Django] #28150: Behavour of django.utils.text.slugify is not consistent

2017-04-28 Thread Django

#28150: Behavour of django.utils.text.slugify is not consistent
-+-
 Reporter:  Marcos Diez  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  slugify unicode  | Triage Stage:
  enconding  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Marcos Diez:

Old description:

> After hours of debugging, I realized the behavior of
> django.utils.text.slugify is not consistent.
>
> On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)
>
> {{{
> original_value = ('test trial', )
> slug = slugify(original_value) # returns "test-trial"
> }}}
>
> but on Python 2.7.12
>
> {{{
> from __future__ return unicode_literals
>
> original_value = ('test trial', )
> slug = slugify(original_value) # returns "utest-trial"
> }}}
>
> This is serious and inconsistent.
> Fixing it is not trivial either because it may cause backwards
> incompatibility.
>
> If I was in charge I would either:
> - Do nothing since python 2.7 will be deprecated
> - Deprecate slugify and create slugify2 which is not affected by this bug
>

>
> Thanks for your time,
> Marcos Diez

New description:

 After hours of debugging, I realized the behavior of
 django.utils.text.slugify is not consistent.

 On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)

 {{{
 from django.utils.text import slugify

 original_value = ('test trial', )
 slug = slugify(original_value) # returns "test-trial"
 }}}

 but on Python 2.7.12

 {{{
 from __future__ return unicode_literals

 from django.utils.text import slugify

 original_value = ('test trial', )
 slug = slugify(original_value) # returns "utest-trial"
 }}}

 This is serious and inconsistent.
 Fixing it is not trivial either because it may cause backwards
 incompatibility.

 If I was in charge I would either:
 - Do nothing since python 2.7 will be deprecated
 - Deprecate slugify and create slugify2 which is not affected by this bug



 Thanks for your time,
 Marcos Diez

--

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

Re: [Django] #28150: Behavour of django.utils.text.slugify is not consistent

2017-04-28 Thread Django

#28150: Behavour of django.utils.text.slugify is not consistent
-+-
 Reporter:  Marcos Diez  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  slugify unicode  | Triage Stage:
  enconding  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Marcos Diez:

Old description:

> After hours of debugging, I realized the behavior of
> django.utils.text.slugify is not consistent.
>
> On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)
>
> 
> original_value = ('test trial', )
> slug = slugify(original_value) # returns "test-trial"
> 
> but on Python 2.7.12
>
> from __future__ return unicode_literals
>
> original_value = ('test trial', )
> slug = slugify(original_value) # returns "utest-trial"
>
> 
> This is serious and inconsistent.
> Fixing it is not trivial either because it may cause backwards
> incompatibility.
>
> If I was in charge I would either:
> - Do nothing since python 2.7 will be deprecated
> - Deprecate slugify and create slugify2 which is not affected by this bug
>

>
> Thanks for your time,
> Marcos Diez

New description:

 After hours of debugging, I realized the behavior of
 django.utils.text.slugify is not consistent.

 On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)

 {{{
 original_value = ('test trial', )
 slug = slugify(original_value) # returns "test-trial"
 }}}

 but on Python 2.7.12

 {{{
 from __future__ return unicode_literals

 original_value = ('test trial', )
 slug = slugify(original_value) # returns "utest-trial"
 }}}

 This is serious and inconsistent.
 Fixing it is not trivial either because it may cause backwards
 incompatibility.

 If I was in charge I would either:
 - Do nothing since python 2.7 will be deprecated
 - Deprecate slugify and create slugify2 which is not affected by this bug



 Thanks for your time,
 Marcos Diez

--

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

[Django] #28150: Behavour of django.utils.text.slugify is not consistent

2017-04-28 Thread Django

#28150: Behavour of django.utils.text.slugify is not consistent
-+-
   Reporter:  Marcos |  Owner:  nobody
  Diez   |
   Type:  Bug| Status:  new
  Component:  Utilities  |Version:  1.11
   Severity:  Normal |   Keywords:  slugify unicode
   Triage Stage: |  enconding
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 After hours of debugging, I realized the behavior of
 django.utils.text.slugify is not consistent.

 On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)

 
 original_value = ('test trial', )
 slug = slugify(original_value) # returns "test-trial"
 
 but on Python 2.7.12

 from __future__ return unicode_literals

 original_value = ('test trial', )
 slug = slugify(original_value) # returns "utest-trial"

 
 This is serious and inconsistent.
 Fixing it is not trivial either because it may cause backwards
 incompatibility.

 If I was in charge I would either:
 - Do nothing since python 2.7 will be deprecated
 - Deprecate slugify and create slugify2 which is not affected by this bug



 Thanks for your time,
 Marcos Diez

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

Re: [Django] #28130: Formset validate_min validation ignores unchanged forms

2017-04-28 Thread Django

#28130: Formset validate_min validation ignores unchanged forms
-+-
 Reporter:  Jim Ouwerkerk|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  formsets | 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 GitHub ):

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


Comment:

 In [changeset:"f04a40491764bdc9a2ebbfc03fa7be424fb3ce63" f04a4049]:
 {{{
 #!CommitTicketReference repository=""
 revision="f04a40491764bdc9a2ebbfc03fa7be424fb3ce63"
 Fixed #28130 -- Fixed formset min_num validation with initial, unchanged
 forms.

 Regression in f5c6295797b8332134fd89e0209a18a1d1d45e0c.
 }}}

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

Re: [Django] #28148: behaviour change on ImageField because of django.core.validators.validate_image_file_extension

2017-04-28 Thread Django

#28148: behaviour change on ImageField because of
django.core.validators.validate_image_file_extension
---+--
 Reporter:  rm_|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  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 rm_):

 Replying to [comment:3 Tim Graham]:
 > We could document the backwards incompatible change. Did you have
 anything else in mind?

 I think a mention of ImageFields name attribute requirements should be
 added in the paragraph that suggests to use StringIO / BytesIO here:
 
https://docs.djangoproject.com/en/1.11/topics/testing/tools/#django.test.Client.post

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

Re: [Django] #20939: Convert QuerySet to Query when filtering

2017-04-28 Thread Django

#20939: Convert QuerySet to Query when filtering
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"eb4724a0632928bda2a512a9117a91260096e457" eb4724a0]:
 {{{
 #!CommitTicketReference repository=""
 revision="eb4724a0632928bda2a512a9117a91260096e457"
 Reverted "Refs #20939 -- Moved subquery ordering clearing optimization to
 the __in lookup."

 This reverts commit e62ea0bb9cbb54c1eef848871fe3eab2bad268dc since it
 broke multi-column __in lookups and _meta.order_wrt on Oracle.
 }}}

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

[Django] #28149: QuerySet model fields comparsion

2017-04-28 Thread Django

#28149: QuerySet model fields comparsion
-+
   Reporter:  vladlutkov |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Uncategorized  |Version:
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 {{{
 AModel.objects.only('id').filter(b_model__b_field=F('a_field'))
 }}}
 generates
 {{{
 SELECT `a_table`.`id` FROM `a_table` INNER JOIN `b_table` ON
 (`a_table`.`id` = `b_table`.`a_table_id`) WHERE `b_table`.`b_field` =
 (`a_table`.`a_field`)
 }}}
 and it's OK, but if you need to make '<>' or '!=' operation between fields
 you try
 {{{
 AModel.objects.only('id').exclude(b_model__b_field=F('a_field'))
 }}}
 and it generates
 {{{
 SELECT `a_table`.`id` FROM `a_table` WHERE NOT (`a_table`.`id` IN (SELECT
 U1.`a_table_id` AS Col1 FROM `a_table` U0 INNER JOIN `b_table` U1 ON
 (U0.`id` = U1.`a_table_id`) WHERE U1.`b_field` = (U0.`a_field`)))
 }}}
 and if you try
 {{{
 .filter(~Q('...'))
 }}}
 you'll get the same sql query

 Need to make a 'ne' lookup (or something else), which will generate '<>'
 or '!=' sql operators

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

Re: [Django] #28148: behaviour change on ImageField because of django.core.validators.validate_image_file_extension

2017-04-28 Thread Django

#28148: behaviour change on ImageField because of
django.core.validators.validate_image_file_extension
---+--
 Reporter:  rm_|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  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 Tim Graham):

 We could document the backwards incompatible change. Did you have anything
 else in mind?

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

Re: [Django] #28148: behaviour change on ImageField because of django.core.validators.validate_image_file_extension (was: bahviour change on ImageField because of django.core.validators.validate_image

2017-04-28 Thread Django

#28148: behaviour change on ImageField because of
django.core.validators.validate_image_file_extension
---+--
 Reporter:  rm_|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by rm_:

Old description:

> The following test code snippet stopped working on django 1.11 raising a
> validation error because the posted image has not a valid file extension:
>
> {{{
> class Test(TestCase):
> def test_post(self):
> img = BytesIO(IMAGE)
> data = {
> 'image': img,
> }
> response = self.client.post(url, data=data)
> }}}
>
> The view takes the data and fill the following ModelForm that fails
> validation:
>
> {{{
> class Image(models.Model):
> image = models.ImageField(_(u'Immagine'), upload_to='image')
>

> class ImageForm(forms.ModelForm):
> class Meta:
> model = Image
> }}}
>
> As a workaround, adding a name attribute to the BytesIO object make the
> code work again:
>
> {{{
> img.name = 'ciao.jpg'
> }}}

New description:

 The following test code snippet stopped working after upgrading django to
 1.11 from 1.10.x. The code now raises a validation error because the
 posted image has not a valid file extension:

 {{{
 class Test(TestCase):
 def test_post(self):
 img = BytesIO(IMAGE)
 data = {
 'image': img,
 }
 response = self.client.post(url, data=data)
 }}}

 The view takes the data and fill the following ModelForm that fails
 validation:

 {{{
 class Image(models.Model):
 image = models.ImageField(_(u'Immagine'), upload_to='image')


 class ImageForm(forms.ModelForm):
 class Meta:
 model = Image
 }}}

 As a workaround, adding a name attribute to the BytesIO object make the
 code work again:

 {{{
 img.name = 'ciao.jpg'
 }}}

--

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

Re: [Django] #28148: bahviour change on ImageField because of django.core.validators.validate_image_file_extension

2017-04-28 Thread Django

#28148: bahviour change on ImageField because of
django.core.validators.validate_image_file_extension
---+--
 Reporter:  rm_|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by rm_:

Old description:

> The following test code snippet stopped working on django 1.11 raising a
> validation error because the posted image has not a valid file extension:
>
> ```
> class Test(TestCase):
> def test_post(self):
> img = BytesIO(IMAGE)
> data = {
> 'image': img,
> }
> response = self.client.post(url, data=data)
> ```
>
> The view takes the data and fill the following ModelForm that fails
> validation:
>
> ```
> class Image(models.Model):
> image = models.ImageField(_(u'Immagine'), upload_to='image')
>

> class ImageForm(forms.ModelForm):
> class Meta:
> model = Image
> ```
>
> As a workaround, adding a name attribute to the BytesIO object make the
> code work again:
>
> ```
> img.name = 'ciao.jpg'
> ```

New description:

 The following test code snippet stopped working on django 1.11 raising a
 validation error because the posted image has not a valid file extension:

 {{{
 class Test(TestCase):
 def test_post(self):
 img = BytesIO(IMAGE)
 data = {
 'image': img,
 }
 response = self.client.post(url, data=data)
 }}}

 The view takes the data and fill the following ModelForm that fails
 validation:

 {{{
 class Image(models.Model):
 image = models.ImageField(_(u'Immagine'), upload_to='image')


 class ImageForm(forms.ModelForm):
 class Meta:
 model = Image
 }}}

 As a workaround, adding a name attribute to the BytesIO object make the
 code work again:

 {{{
 img.name = 'ciao.jpg'
 }}}

--

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

[Django] #28148: bahviour change on ImageField because of django.core.validators.validate_image_file_extension

2017-04-28 Thread Django

#28148: bahviour change on ImageField because of
django.core.validators.validate_image_file_extension
-+
   Reporter:  rm_|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Forms  |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  |
-+
 The following test code snippet stopped working on django 1.11 raising a
 validation error because the posted image has not a valid file extension:

 ```
 class Test(TestCase):
 def test_post(self):
 img = BytesIO(IMAGE)
 data = {
 'image': img,
 }
 response = self.client.post(url, data=data)
 ```

 The view takes the data and fill the following ModelForm that fails
 validation:

 ```
 class Image(models.Model):
 image = models.ImageField(_(u'Immagine'), upload_to='image')


 class ImageForm(forms.ModelForm):
 class Meta:
 model = Image
 ```

 As a workaround, adding a name attribute to the BytesIO object make the
 code work again:

 ```
 img.name = 'ciao.jpg'
 ```

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

Re: [Django] #28146: PostGIS: Django 1.11 adds two extra queries: SELECT postgis_lib_version() and SELECT version()

2017-04-28 Thread Django

#28146: PostGIS: Django 1.11 adds two extra queries: SELECT 
postgis_lib_version()
and SELECT version()
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  GIS  |  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 George Tantiras):

 Yes, I will try to bisect and report the commit.

 Please note that after upgrading, debug toolbar always reports those two
 queries.

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

Re: [Django] #28146: PostGIS: Django 1.11 adds two extra queries: SELECT postgis_lib_version() and SELECT version()

2017-04-28 Thread Django

#28146: PostGIS: Django 1.11 adds two extra queries: SELECT 
postgis_lib_version()
and SELECT version()
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  GIS  |  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 Tim Graham):

 * component:  Uncategorized => GIS
 * type:  Uncategorized => Cleanup/optimization


Comment:

 Could you [https://docs.djangoproject.com/en/dev/internals/contributing
 /triaging-tickets/#bisecting-a-regression bisect] to find the commit where
 the behavior changed? It might be that there's a bug, but typically any
 version queries should be cached by the server so they don't run for every
 request.

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

Re: [Django] #28143: CSRF token fails when Debug is disabled and a custom view is used for handler404

2017-04-28 Thread Django

#28143: CSRF token fails when Debug is disabled and a custom view is used for
handler404
-+--
 Reporter:  antigaprime  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  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 Tim Graham):

 Can you explain why Django is at fault, or are you looking for help to
 debug your application? In the latter case, you should
 TicketClosingReasons/UseSupportChannels rather than this ticket tracker.

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

Re: [Django] #28147: Saving parent object after setting on child leads to unexpected data loss

2017-04-28 Thread Django

#28147: Saving parent object after setting on child leads to unexpected data 
loss
-+-
 Reporter:  Erwin Junge  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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
-+-
Description changed by Erwin Junge:

Old description:

> When saving a parent object after setting it on a child object and then
> saving the child object, no error is thrown but the FK relation is saved
> with a NULL value.
>
> Failing testcase:
> {{{
> # Create parent and child, save parent, save child, parent_id
> should be set
> p = Parent()
> c = Child(parent=p)
> p.save()
> c.save()
> c.refresh_from_db()
> self.assertIs(c.parent, p)
> }}}

New description:

 When saving a parent object after setting it on a child object and then
 saving the child object, no error is thrown but the FK relation is saved
 with a NULL value.

 Failing testcase:
 {{{
 # Create parent and child, save parent, save child, parent_id
 should be set
 p = Parent()
 c = Child(parent=p)
 p.save()
 c.save()
 c.refresh_from_db()
 self.assertIs(c.parent, p)
 }}}

 Patch available: https://github.com/django/django/pull/8434

--

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

[Django] #28147: Saving parent object after setting on child leads to unexpected data loss

2017-04-28 Thread Django

#28147: Saving parent object after setting on child leads to unexpected data 
loss
-+-
   Reporter:  Erwin  |  Owner:  nobody
  Junge  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When saving a parent object after setting it on a child object and then
 saving the child object, no error is thrown but the FK relation is saved
 with a NULL value.

 Failing testcase:
 {{{
 # Create parent and child, save parent, save child, parent_id
 should be set
 p = Parent()
 c = Child(parent=p)
 p.save()
 c.save()
 c.refresh_from_db()
 self.assertIs(c.parent, p)
 }}}

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

51 matches

Mail list logo