Re: [Django] #29305: GET or POST requests outside of the browser to the LiveServerTestCase hang

[Django]

#29305: GET or POST requests outside of the browser to the LiveServerTestCase 
hang
---+--
 Reporter:  Santiago García|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  Test   | 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 Santiago García:

Old description:

> We have an integration test where we start two separate Django processes
> and the second process makes a POST request to the first process with the
> requests library. This testcase broke once we upgraded to Django 1.11,
> while it still worked in Django 1.10.
>
> To reproduce the issue:
>
> - Create a simple Django app.
> - Install selenium and requests
> - Add a testcase like so:
>

>   {{{#!python
> import time
>
> from django.contrib.staticfiles.testing import StaticLiveServerTestCase
> from django.urls import reverse
> from selenium import webdriver
>

> class TestExample(StaticLiveServerTestCase):
> def test_example(self):
> driver = webdriver.Chrome()
> driver.get(self.live_server_url + reverse('admin:index'))
> # wait "forever"
> time.sleep(60 * 60 * 24)
>   }}}
>
> I.e it just opens the admin page, then waits for 24 hours. In a Python
> console, type the following:
>
>   {{{#!python
> import requests
> requests.get('http://localhost:47256/admin')
>   }}}
>
> and you will see that the request hangs indefinitely. Interestingly, it
> sometimes helps to press refresh in the Chrome window spawned by
> Selenium.

New description:

 We have an integration test where we start two separate Django processes
 and the second process makes a POST request to the first process with the
 requests library. This testcase broke once we upgraded to Django 1.11,
 while it still worked in Django 1.10.

 To reproduce the issue:

 - Create a simple Django app.
 - Install selenium and requests
 - Add a testcase like so:


   {{{#!python
 import time

 from django.contrib.staticfiles.testing import StaticLiveServerTestCase
 from django.urls import reverse
 from selenium import webdriver


 class TestExample(StaticLiveServerTestCase):
 def test_example(self):
 driver = webdriver.Chrome()
 driver.get(self.live_server_url + reverse('admin:index'))
 # wait "forever"
 time.sleep(60 * 60 * 24)
   }}}

 I.e it just opens the admin page, then waits for 24 hours. In a Python
 console, type the following:

   {{{#!python
 import requests
 requests.get('http://localhost:47256/admin') # replace 47256 with whatever
 port number the LiveServerTestCase picked
   }}}

 and you will see that the request hangs indefinitely. Interestingly, it
 sometimes helps to press refresh in the Chrome window spawned by Selenium.

--

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

Re: [Django] #24128: Admindocs doesn't account for template loaders

[Django]

#24128: Admindocs doesn't account for template loaders
---+
 Reporter:  Aymeric Augustin   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admindocs  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Gunnar Ahlberg):

 I tested this patch. It works nicely for me

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

[Django] #29305: GET or POST requests outside of the browser to the LiveServerTestCase hang

[Django]

#29305: GET or POST requests outside of the browser to the LiveServerTestCase 
hang
-+
   Reporter:  Santiago García|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  1.11
   Severity:  Normal |   Keywords:  Test
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 We have an integration test where we start two separate Django processes
 and the second process makes a POST request to the first process with the
 requests library. This testcase broke once we upgraded to Django 1.11,
 while it still worked in Django 1.10.

 To reproduce the issue:

 - Create a simple Django app.
 - Install selenium and requests
 - Add a testcase like so:


   {{{#!python
 import time

 from django.contrib.staticfiles.testing import StaticLiveServerTestCase
 from django.urls import reverse
 from selenium import webdriver


 class TestExample(StaticLiveServerTestCase):
 def test_example(self):
 driver = webdriver.Chrome()
 driver.get(self.live_server_url + reverse('admin:index'))
 # wait "forever"
 time.sleep(60 * 60 * 24)
   }}}

 I.e it just opens the admin page, then waits for 24 hours. In a Python
 console, type the following:

   {{{#!python
 import requests
 requests.get('http://localhost:47256/admin')
   }}}

 and you will see that the request hangs indefinitely. Interestingly, it
 sometimes helps to press refresh in the Chrome window spawned by Selenium.

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

Re: [Django] #28062: Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor errors

[Django]

#28062: Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor 
errors
-+-
 Reporter:  Sergey Fursov|Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 [https://github.com/django/django/pull/9863 PR] for an addition to the
 1.11 release notes.

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

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

[Django] #29307: Incorrect introspection of django.contrib.postgres fields.

[Django]

#29307: Incorrect introspection of django.contrib.postgres fields.
--+
   Reporter:  Alasdair Nicol  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  2.0
   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 introspection rules for django.contrib.postgres fields incorrectly use
 `django.contrib.postgresql`.

 
https://github.com/django/django/blob/a599ae6018f748f66e774604d12989911ea09d33/django/contrib/postgres/apps.py#L20

 As reported on [https://stackoverflow.com/questions/49736688/inspectdb-
 command-for-json-in-django2-generates-django-contrib-postgresql-
 fields/49737317#49737317 Stack Overflow]

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

Re: [Django] #29307: Incorrect introspection of django.contrib.postgres fields.

[Django]

#29307: Incorrect introspection of django.contrib.postgres fields.
+--
 Reporter:  Alasdair Nicol  |Owner:  Alasdair Nicol
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  2.0
 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 Alasdair Nicol):

 * status:  new => assigned
 * owner:  nobody => Alasdair Nicol


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

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

Re: [Django] #29307: inspectdb generates Incorrect import paths for contrib.postgres fields (was: Incorrect introspection of django.contrib.postgres fields.)

[Django]

#29307: inspectdb generates Incorrect import paths for contrib.postgres fields
-+-
 Reporter:  Alasdair Nicol   |Owner:  Alasdair
 |  Nicol
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  2.0
 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):

 * component:  Migrations => contrib.postgres
 * 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/071.45aff3284ff6d526095e5e6256e4cf5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29305: GET or POST requests outside of the browser to the LiveServerTestCase server hang (was: GET or POST requests outside of the browser to the LiveServerTestCase hang)

[Django]

#29305: GET or POST requests outside of the browser to the LiveServerTestCase
server hang
---+--
 Reporter:  Santiago García|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  Test   | 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/075.1e984cdefdf3c3e0e6125011b2d6a530%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29305: GET or POST requests outside of the browser to the LiveServerTestCase server hang

[Django]

#29305: GET or POST requests outside of the browser to the LiveServerTestCase
server hang
---+--
 Reporter:  Santiago García|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  Test   | 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 Santiago García:

Old description:

> We have an integration test where we start two separate Django processes
> and the second process makes a POST request to the first process with the
> requests library. This testcase broke once we upgraded to Django 1.11,
> while it still worked in Django 1.10.
>
> To reproduce the issue:
>
> - Create a simple Django app.
> - Install selenium and requests
> - Add a testcase like so:
>

>   {{{#!python
> import time
>
> from django.contrib.staticfiles.testing import StaticLiveServerTestCase
> from django.urls import reverse
> from selenium import webdriver
>

> class TestExample(StaticLiveServerTestCase):
> def test_example(self):
> driver = webdriver.Chrome()
> driver.get(self.live_server_url + reverse('admin:index'))
> # wait "forever"
> time.sleep(60 * 60 * 24)
>   }}}
>
> I.e it just opens the admin page, then waits for 24 hours. In a Python
> console, type the following:
>
>   {{{#!python
> import requests
> requests.get('http://localhost:47256/admin') # replace 47256 with
> whatever port number the LiveServerTestCase picked
>   }}}
>
> and you will see that the request hangs indefinitely. Interestingly, it
> sometimes helps to press refresh in the Chrome window spawned by
> Selenium.

New description:

 We have an integration test where we start two separate Django processes
 and the second process makes a POST request to the first process with the
 requests library. This testcase broke once we upgraded to Django 1.11,
 while it still worked in Django 1.10.

 To reproduce the issue:

 - Create a simple Django app.
 - Install selenium and requests
 - Add a testcase like so:


   {{{#!python
 import time

 from django.contrib.staticfiles.testing import StaticLiveServerTestCase
 from django.urls import reverse
 from selenium import webdriver


 class TestExample(StaticLiveServerTestCase):
 def test_example(self):
 driver = webdriver.Chrome()
 driver.get(self.live_server_url + reverse('admin:index'))
 # wait "forever"
 time.sleep(60 * 60 * 24)
   }}}

 I.e it just opens the admin page in Chrome, then waits for 24 hours. In a
 Python console, type the following:

   {{{#!python
 import requests
 requests.get('http://localhost:47256/admin') # replace 47256 with whatever
 port number the LiveServerTestCase picked
   }}}

 and you will see that the request hangs indefinitely. Interestingly, it
 sometimes helps to press refresh in the Chrome window spawned by Selenium.

--

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

Re: [Django] #29304: QuerySet.bulk_create() fails with "ORA-01790: expression must have same datatype as corresponding expression"

[Django]

#29304: QuerySet.bulk_create() fails with "ORA-01790: expression must have same
datatype as corresponding expression"
-+-
 Reporter:  isergey  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 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 felixxm):

 * cc: felixxm (added)


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

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

Re: [Django] #29304: QuerySet.bulk_create() fails with "ORA-01790: expression must have same datatype as corresponding expression" (was: Bulk Create bug in ORACLE)

[Django]

#29304: QuerySet.bulk_create() fails with "ORA-01790: expression must have same
datatype as corresponding expression"
-+-
 Reporter:  isergey  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Old description:

> I have to models
> {{{
> class Record(models.Model):
> hash = models.CharField(max_length=32)
> source = models.ForeignKey(Source, on_delete=models.CASCADE)
> create_date = models.DateTimeField(db_index=True)
> update_date = models.DateTimeField(db_index=True)
> deleted = models.BooleanField(default=False, db_index=True)
>

> class RecordContent(models.Model):
> record = models.OneToOneField(Record, primary_key=True,
> on_delete=models.CASCADE)
> content = models.TextField(max_length=100 * 1024)
> }}}
> In MySQL this function works fine:
> {{{
> def _create_records(record_containers):
> records = []
> record_contents = []
> for record_container in record_containers:
> records.append(record_container['record'])
> record_contents.append(record_container['content'])
>
> models.Record.objects.bulk_create(records)
> models.RecordContent.objects.bulk_create(record_contents) # in Oracle
> ORA-01790: expression must have same datatype as corresponding expression
> }}}
> But in Oracle this code thows exception: ORA-01790: expression must have
> same datatype as corresponding expression
>
> If refactor the function _create_records:
> {{{
> def _create_records(record_containers):
> for record_container in record_containers:
> models.Record.objects.bulk_create([record_container['record']])
> models.RecordContent.objects.bulk_create([record_container['content']])
> }}}
> there is no exception is thrown.
>
> What happens?

New description:

 I have two models:
 {{{
 class Record(models.Model):
 hash = models.CharField(max_length=32)
 source = models.ForeignKey(Source, on_delete=models.CASCADE)
 create_date = models.DateTimeField(db_index=True)
 update_date = models.DateTimeField(db_index=True)
 deleted = models.BooleanField(default=False, db_index=True)


 class RecordContent(models.Model):
 record = models.OneToOneField(Record, primary_key=True,
 on_delete=models.CASCADE)
 content = models.TextField(max_length=100 * 1024)
 }}}
 In MySQL this function works fine:
 {{{
 def _create_records(record_containers):
 records = []
 record_contents = []
 for record_container in record_containers:
 records.append(record_container['record'])
 record_contents.append(record_container['content'])

 models.Record.objects.bulk_create(records)
 models.RecordContent.objects.bulk_create(record_contents) # in Oracle
 ORA-01790: expression must have same datatype as corresponding expression
 }}}
 But in Oracle this code thows exception: ORA-01790: expression must have
 same datatype as corresponding expression

 If refactor the function _create_records:
 {{{
 def _create_records(record_containers):
 for record_container in record_containers:
 models.Record.objects.bulk_create([record_container['record']])
 models.RecordContent.objects.bulk_create([record_container['content']])
 }}}
 there is no exception is thrown.

 What happens?

--

Comment:

 What version of Django are you using? It might be a duplicate of #22669
 (fixed in Django 2.0). If not, please try to minimize the code to
 reproduce the issue, including the data that causes the crash.

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

Re: [Django] #28935: Template error raised in an {% extends %} child template shows incorrect source location on debug page

[Django]

#28935: Template error raised in an {% extends %} child template shows incorrect
source location on debug page
-+
 Reporter:  Matt Westcott|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Collin Anderson):

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

Re: [Django] #29193: Altering a field with a unique constraint drops and rebuilds FKs to other fields in the table

[Django]

#29193: Altering a field with a unique constraint drops and rebuilds FKs to 
other
fields in the table
-+-
 Reporter:  Jeremy Bowman|Owner:  Jeremy Bowman
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Release blocker  |   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 Jeremy Bowman):

 * owner:  nobody => Jeremy Bowman
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 I've [https://github.com/django/django/pull/9866 submitted a PR] for this;
 the problem with my first attempt above was that foreign keys which don't
 specify a target field end up with `to_fields` set to `[None]` instead of
 `['id']`.  The new version correctly handles this case, splits out the
 relevant logic into a separate function, and adds a regression test which
 counts the number of SQL statements executed by a unique field alteration
 that previously dropped and recreated an FK on the primary key of its
 table.

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

[Django] #29308: Testing: assertQuerysetEqual's transform parameter not applied to the values parameter

[Django]

#29308: Testing: assertQuerysetEqual's transform parameter not applied to the
values parameter
-+
   Reporter:  Alexander Todorov  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  2.0
   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  |
-+
 According to:
 
https://docs.djangoproject.com/en/2.0/topics/testing/tools/#django.test.TransactionTestCase.assertQuerysetEqual

 > Asserts that a queryset `qs` returns a particular list of values
 `values`.
 >
 > The comparison of the contents of `qs` and `values` is performed using
 the function `transform`;

 The way I read this is that this assert method receives a queryset and a
 list parameters and compares their contents for equality. By default it
 will use `repr` to do that but the user can change this. The way the docs
 are written suggests that the `transform` function is applied to both the
 queryset and the `values` list. In other words in my tests I can write:

 ``
 self.assertQuerysetEqual(some_query_taken_from_request_context,
 [test_object1, test_object2, etc])
 ``

 The tutorial doesn't use the above but instead hard codes string
 representations in the tests:
 https://docs.djangoproject.com/en/2.0/intro/tutorial05/#testing-our-new-
 view


 IMO this is less optimal, makes test suites more fragile (dependent on
 repr()) and less intuitive b/c the expected value isn't a list of the
 actual objects but a list of their representation which may have been
 obtained elsewhere.


 Note: this may sounds like an RFE but if we trust the docs it's a bug.

 Note2: I can contribute a PR for this and update the existing test suite &
 docs. Just let me know how you feel about it.

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

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

Re: [Django] #29306: [bugs]Template variable-lookups system invoke class when access class attribute (was: [bugs for all version]Template variable-lookups system evaluate callables before completed th

[Django]

#29306: [bugs]Template variable-lookups system invoke class when access class
attribute
-+--
 Reporter:  Luoxzhg  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  template | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Description changed by Luoxzhg:

Old description:

> {{{
> class A:
> class B:
>  attr="Hello"
>
> from django.template import Template, Context
> t = Template(" {{  A.B.attr }}")
> output=t.render(Context({"A": A}))
> }}}
>
> the output should be "Hello", but it is string_if_invalid, i.e., empty
> string "" .

New description:

 {{{
 class A:
 def __init__(self, value):
  pass
 attr="Hello"

 from django.template import Template, Context
 t = Template(" {{  A.attr }}")
 output=t.render(Context({"A": A}))
 }}}

 the output should be "Hello", but it is string_if_invalid, i.e., empty
 string "" .

--

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

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

Re: [Django] #29306: [bugs]Template variable-lookups system invoke class when access class attribute

[Django]

#29306: [bugs]Template variable-lookups system invoke class when access class
attribute
-+--
 Reporter:  Luoxzhg  |Owner:  Luoxzhg
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  template | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by Luoxzhg):

 * status:  new => assigned
 * owner:  nobody => Luoxzhg


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

Re: [Django] #29305: GET or POST requests outside of the browser to the LiveServerTestCase server hang

[Django]

#29305: GET or POST requests outside of the browser to the LiveServerTestCase
server hang
---+--
 Reporter:  Santiago García|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  Test   | 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 Santiago García:

Old description:

> We have an integration test where we start two separate Django processes
> and the second process makes a POST request to the first process with the
> requests library. This testcase broke once we upgraded to Django 1.11,
> while it still worked in Django 1.10.
>
> To reproduce the issue:
>
> - Create a simple Django app.
> - Install selenium and requests
> - Add a testcase like so:
>

>   {{{#!python
> import time
>
> from django.contrib.staticfiles.testing import StaticLiveServerTestCase
> from django.urls import reverse
> from selenium import webdriver
>

> class TestExample(StaticLiveServerTestCase):
> def test_example(self):
> driver = webdriver.Chrome()
> driver.get(self.live_server_url + reverse('admin:index'))
> # wait "forever"
> time.sleep(60 * 60 * 24)
>   }}}
>
> I.e it just opens the admin page in Chrome, then waits for 24 hours. In a
> Python console, type the following:
>
>   {{{#!python
> import requests
> requests.get('http://localhost:47256/admin') # replace 47256 with
> whatever port number the LiveServerTestCase picked
>   }}}
>
> and you will see that the request hangs indefinitely. Interestingly, it
> sometimes helps to press refresh in the Chrome window spawned by
> Selenium.

New description:

 We have an integration test where we start two separate Django processes
 and the second process makes a POST request to the first process with the
 requests library. This testcase broke once we upgraded to Django 1.11,
 while it still worked in Django 1.10.

 To reproduce the issue:

 - Create a simple Django app.
 - Install selenium and requests
 - Add a testcase like so:


   {{{#!python
 import time

 from django.contrib.staticfiles.testing import StaticLiveServerTestCase
 from django.urls import reverse
 from selenium import webdriver


 class TestExample(StaticLiveServerTestCase):
 def test_example(self):
 driver = webdriver.Chrome()
 driver.get(self.live_server_url + reverse('admin:index'))
 # wait "forever"
 time.sleep(60 * 60 * 24)
   }}}

 I.e it just opens the admin page in Chrome, then waits for 24 hours. In a
 Python console, type the following:

   {{{#!python
 import requests
 requests.get('http://localhost:47256/admin') # replace 47256 with whatever
 port number the LiveServerTestCase picked
   }}}

 and you will see that the request hangs indefinitely. Interestingly, it
 sometimes helps to press refresh in the Chrome window spawned by Selenium.

 I am seeing this issue on Windows 7 and Windows 10 machines

--

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

[Django] #29306: [bugs for all version]Template variable-lookups system evaluate callables before completed the evaluation

[Django]

#29306: [bugs for all version]Template variable-lookups system evaluate 
callables
before completed the evaluation
---+--
   Reporter:  Luoxzhg  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:  template
   Triage Stage:  Unreviewed   |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+--
 {{{
 class A:
 class B:
  attr="Hello"

 from django.template import Template, Context
 t = Template(" {{  A.B.attr }}")
 output=t.render(Context({"A": A}))
 }}}

 the output should be "Hello", but it is string_if_invalid, i.e., empty
 string "" .

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

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

Re: [Django] #29307: inspectdb generates Incorrect import paths for contrib.postgres fields

[Django]

#29307: inspectdb generates Incorrect import paths for contrib.postgres fields
-+-
 Reporter:  Alasdair Nicol   |Owner:  Alasdair
 |  Nicol
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  2.0
 Severity:  Release blocker  |   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 Alasdair Nicol):

 * has_patch:  0 => 1


Comment:

 Pull request: https://github.com/django/django/pull/9865

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

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

[Django] #29304: Bulk Create bug in ORACLE

[Django]

#29304: Bulk Create bug in ORACLE
-+
   Reporter:  isergey|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.0
   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  |
-+
 I have to models
 {{{
 class Record(models.Model):
 id = models.CharField(primary_key=True, max_length=32)
 original_id = models.TextField(max_length=2048, blank=True)
 hash = models.CharField(max_length=32)
 source = models.ForeignKey(Source, on_delete=models.CASCADE)
 schema = models.CharField(max_length=32)
 session_id = models.BigIntegerField(default=0)
 create_date = models.DateTimeField(db_index=True)
 update_date = models.DateTimeField(db_index=True)
 deleted = models.BooleanField(default=False, db_index=True)


 class RecordContent(models.Model):
 record = models.OneToOneField(Record, primary_key=True,
 on_delete=models.CASCADE)
 content = models.TextField(max_length=100 * 1024)
 }}}
 In MySQL this function works fine:
 {{{
 def _create_records(record_containers):
 records = []
 record_contents = []
 for record_container in record_containers:
 records.append(record_container['record'])
 record_contents.append(record_container['content'])

 models.Record.objects.bulk_create(records)
 models.RecordContent.objects.bulk_create(record_contents)
 }}}
 But in Oracle this code thows exception: ORA-01790: expression must have
 same datatype as corresponding expression

 If refactor the function _create_records:
 {{{
 def _create_records(record_containers):
 for record_container in record_containers:
 models.Record.objects.bulk_create([record_container['record']])
 models.RecordContent.objects.bulk_create([record_container['content']])
 }}}
 there is no exception is thrown.

 What happens?

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

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

Re: [Django] #29304: Bulk Create bug in ORACLE

[Django]

#29304: Bulk Create bug in ORACLE
---+--
 Reporter:  isergey|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.0
 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 isergey:

Old description:

> I have to models
> {{{
> class Record(models.Model):
> id = models.CharField(primary_key=True, max_length=32)
> original_id = models.TextField(max_length=2048, blank=True)
> hash = models.CharField(max_length=32)
> source = models.ForeignKey(Source, on_delete=models.CASCADE)
> schema = models.CharField(max_length=32)
> session_id = models.BigIntegerField(default=0)
> create_date = models.DateTimeField(db_index=True)
> update_date = models.DateTimeField(db_index=True)
> deleted = models.BooleanField(default=False, db_index=True)
>

> class RecordContent(models.Model):
> record = models.OneToOneField(Record, primary_key=True,
> on_delete=models.CASCADE)
> content = models.TextField(max_length=100 * 1024)
> }}}
> In MySQL this function works fine:
> {{{
> def _create_records(record_containers):
> records = []
> record_contents = []
> for record_container in record_containers:
> records.append(record_container['record'])
> record_contents.append(record_container['content'])
>
> models.Record.objects.bulk_create(records)
> models.RecordContent.objects.bulk_create(record_contents)
> }}}
> But in Oracle this code thows exception: ORA-01790: expression must have
> same datatype as corresponding expression
>
> If refactor the function _create_records:
> {{{
> def _create_records(record_containers):
> for record_container in record_containers:
> models.Record.objects.bulk_create([record_container['record']])
> models.RecordContent.objects.bulk_create([record_container['content']])
> }}}
> there is no exception is thrown.
>
> What happens?

New description:

 I have to models
 {{{
 class Record(models.Model):
 hash = models.CharField(max_length=32)
 source = models.ForeignKey(Source, on_delete=models.CASCADE)
 create_date = models.DateTimeField(db_index=True)
 update_date = models.DateTimeField(db_index=True)
 deleted = models.BooleanField(default=False, db_index=True)


 class RecordContent(models.Model):
 record = models.OneToOneField(Record, primary_key=True,
 on_delete=models.CASCADE)
 content = models.TextField(max_length=100 * 1024)
 }}}
 In MySQL this function works fine:
 {{{
 def _create_records(record_containers):
 records = []
 record_contents = []
 for record_container in record_containers:
 records.append(record_container['record'])
 record_contents.append(record_container['content'])

 models.Record.objects.bulk_create(records)
 models.RecordContent.objects.bulk_create(record_contents)
 }}}
 But in Oracle this code thows exception: ORA-01790: expression must have
 same datatype as corresponding expression

 If refactor the function _create_records:
 {{{
 def _create_records(record_containers):
 for record_container in record_containers:
 models.Record.objects.bulk_create([record_container['record']])
 models.RecordContent.objects.bulk_create([record_container['content']])
 }}}
 there is no exception is thrown.

 What happens?

--

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

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

Re: [Django] #29304: Bulk Create bug in ORACLE

[Django]

#29304: Bulk Create bug in ORACLE
---+--
 Reporter:  isergey|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.0
 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 isergey:

Old description:

> I have to models
> {{{
> class Record(models.Model):
> hash = models.CharField(max_length=32)
> source = models.ForeignKey(Source, on_delete=models.CASCADE)
> create_date = models.DateTimeField(db_index=True)
> update_date = models.DateTimeField(db_index=True)
> deleted = models.BooleanField(default=False, db_index=True)
>

> class RecordContent(models.Model):
> record = models.OneToOneField(Record, primary_key=True,
> on_delete=models.CASCADE)
> content = models.TextField(max_length=100 * 1024)
> }}}
> In MySQL this function works fine:
> {{{
> def _create_records(record_containers):
> records = []
> record_contents = []
> for record_container in record_containers:
> records.append(record_container['record'])
> record_contents.append(record_container['content'])
>
> models.Record.objects.bulk_create(records)
> models.RecordContent.objects.bulk_create(record_contents)
> }}}
> But in Oracle this code thows exception: ORA-01790: expression must have
> same datatype as corresponding expression
>
> If refactor the function _create_records:
> {{{
> def _create_records(record_containers):
> for record_container in record_containers:
> models.Record.objects.bulk_create([record_container['record']])
> models.RecordContent.objects.bulk_create([record_container['content']])
> }}}
> there is no exception is thrown.
>
> What happens?

New description:

 I have to models
 {{{
 class Record(models.Model):
 hash = models.CharField(max_length=32)
 source = models.ForeignKey(Source, on_delete=models.CASCADE)
 create_date = models.DateTimeField(db_index=True)
 update_date = models.DateTimeField(db_index=True)
 deleted = models.BooleanField(default=False, db_index=True)


 class RecordContent(models.Model):
 record = models.OneToOneField(Record, primary_key=True,
 on_delete=models.CASCADE)
 content = models.TextField(max_length=100 * 1024)
 }}}
 In MySQL this function works fine:
 {{{
 def _create_records(record_containers):
 records = []
 record_contents = []
 for record_container in record_containers:
 records.append(record_container['record'])
 record_contents.append(record_container['content'])

 models.Record.objects.bulk_create(records)
 models.RecordContent.objects.bulk_create(record_contents) # in Oracle
 ORA-01790: expression must have same datatype as corresponding expression
 }}}
 But in Oracle this code thows exception: ORA-01790: expression must have
 same datatype as corresponding expression

 If refactor the function _create_records:
 {{{
 def _create_records(record_containers):
 for record_container in record_containers:
 models.Record.objects.bulk_create([record_container['record']])
 models.RecordContent.objects.bulk_create([record_container['content']])
 }}}
 there is no exception is thrown.

 What happens?

--

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

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

[Django] #29309: Recommended MySQL Setup Does Not Work Properly

[Django]

#29309: Recommended MySQL Setup Does Not Work Properly
-+-
   Reporter: |  Owner:  nobody
  NewReStarter   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  2.0
  Documentation  |
   Severity:  Normal |   Keywords:  Database Setup
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Python 3.6.1
 Django 2.0
 Mac OS 10.13.3

 Following the instruction given in
 https://docs.djangoproject.com/en/2.0/ref/databases/#mysql-notes,
 installed pymysql with pip and then modified the settings.py to set up the
 adaptor according to https://dev.mysql.com/doc/connector-python/en
 /connector-python-django-backend.html, the url given by the official
 document.

 Then when executing {{{python3 manage.py makemigrations}}} error appears
 which displays {{{ImportError: No module named 'MySQLdb}}}. It is likely
 that django still uses MySQLdb, which is not supported by python3, as
 default in the release.

 The fix that works for me would be adding following code in the
 {{{__init__.py}}} of the site to use pymysql to replace mysqldb.

 {{{
 import pymysql
 pymysql.install_as_MySQLdb()
 }}}

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

Re: [Django] #28779: Customizing REDIRECT_FIELD_NAME is cumbersome

[Django]

#28779: Customizing REDIRECT_FIELD_NAME is cumbersome
--+
 Reporter:  Meiyer|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  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 Mateusz Kurowski):

 Here is a monkey patch i am using.
 In the apps.py ready method.
 {{{
  def ready(self):
 from django.conf import settings
 from django.contrib import auth
 auth.REDIRECT_FIELD_NAME = settings.REDIRECT_FIELD_NAME
 }}}

 I think its good for the security to allow this customization. It's always
 good to make identification of the framework running website harder.

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

Re: [Django] #29302: Support for MySQL's (>=5.6.1) accurate spatial functions

[Django]

#29302: Support for MySQL's (>=5.6.1) accurate spatial functions
+--
 Reporter:  Shiv Baishya|Owner:  nobody
 Type:  New feature |   Status:  new
Component:  GIS |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  MySQL GEOS Spatial  | 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 Shiv Baishya:

Old description:

> MySQL >=5.6.1 support accurate spatial functions, a.k.a,
> [https://dev.mysql.com/doc/refman/5.6/en/spatial-function-reference.html
> ST_ functions]. Django 1.11 still uses MySQL's old MBR (minimum bounding
> rectangle) functions.
> \\
> I am willing to migrate my
> [https://github.com/shiviser/django/tree/1.9.2_ST_build patch for django
> 1.9.2] to django 1.11 and create a pull request.
> \\
> Here is an elaborated [https://www.percona.com/blog/2013/10/21/using-the-
> new-mysql-spatial-functions-5-6-for-geo-enabled-applications/ article] on
> the advantages of the new MySQL's **ST_ functions**.
> \\
> **Related tickets**
> * https://code.djangoproject.com/ticket/22423
> * https://code.djangoproject.com/ticket/27574

New description:

 MySQL >=5.6.1 support accurate spatial functions, a.k.a,
 [https://dev.mysql.com/doc/refman/5.6/en/spatial-function-reference.html
 ST_ functions]. Django 1.11 still uses MySQL's old MBR (minimum bounding
 rectangle) functions.
 \\
 I am willing to migrate my
 [https://github.com/shiviser/django/tree/1.9.2_ST_build patch for django
 1.9.2] to django 1.11 and create a pull request.
 \\
 Here is an elaborated [https://www.percona.com/blog/2013/10/21/using-the-
 new-mysql-spatial-functions-5-6-for-geo-enabled-applications/ article] on
 the advantages of the new MySQL's **ST_ functions**.
 \\
 **Related tickets**
 * https://code.djangoproject.com/ticket/22423 (4 years old, is anyone
 working on this?)
 * https://code.djangoproject.com/ticket/27574

--

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

Re: [Django] #29302: Support for MySQL's (>=5.6.1) accurate spatial functions

[Django]

#29302: Support for MySQL's (>=5.6.1) accurate spatial functions
+--
 Reporter:  Shiv Baishya|Owner:  nobody
 Type:  New feature |   Status:  new
Component:  GIS |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  MySQL GEOS Spatial  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Shiv Baishya):

 * cc: Shiv Baishya (added)
 * keywords:  MySQL GEOS => MySQL GEOS Spatial


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

Re: [Django] #29302: Support for MySQL's (>=5.6.1) accurate spatial functions

[Django]

#29302: Support for MySQL's (>=5.6.1) accurate spatial functions
+--
 Reporter:  Shiv Baishya|Owner:  nobody
 Type:  New feature |   Status:  new
Component:  GIS |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  MySQL GEOS Spatial  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Tim Graham):

 This looks like a duplicate of #22423. Have I misunderstood the issue? Did
 you see the patch in that ticket? Maybe you can update that patch and fix
 the failure. If so, please send the pull request to master. Per our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy]. Django 1.11 only receives
 security and data loss fixes at this time.

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

Re: [Django] #29202: KeyError in django-sites caching (race condition?)

[Django]

#29202: KeyError in django-sites caching (race condition?)
+--
 Reporter:  Dominik George  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.sites   |  Version:  1.10
 Severity:  Normal  |   Resolution:  needsinfo
 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 Dominik George):

 Nope, it's not a duplicate.

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

[Django] #29302: Support for MySQL's (>=5.6.1) accurate spatial functions

[Django]

#29302: Support for MySQL's (>=5.6.1) accurate spatial functions
+
   Reporter:  Shiv Baishya  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  GIS   |Version:  1.11
   Severity:  Normal|   Keywords:  MySQL GEOS
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 MySQL >=5.6.1 support accurate spatial functions, a.k.a,
 [https://dev.mysql.com/doc/refman/5.6/en/spatial-function-reference.html
 ST_ functions]. Django 1.11 still uses MySQL's old MBR (minimum bounding
 rectangle) functions.
 \\
 I am willing to migrate my
 [https://github.com/shiviser/django/tree/1.9.2_ST_build patch for django
 1.9.2] to django 1.11 and create a pull request.
 \\
 Here is an elaborated [https://www.percona.com/blog/2013/10/21/using-the-
 new-mysql-spatial-functions-5-6-for-geo-enabled-applications/ article] on
 the advantages of the new MySQL's **ST_ functions**.
 \\
 **Related tickets**
 * https://code.djangoproject.com/ticket/22423
 * https://code.djangoproject.com/ticket/27574

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

Re: [Django] #28062: Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor errors

[Django]

#28062: Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor 
errors
-+-
 Reporter:  Sergey Fursov|Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Luke Plant):

 There really needs to be a note about this in the 1.11 release notes, as
 it's a breaking change that affects a pretty common set up. There is a
 note only in the 1.11.1 notes, which is not where people look.

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

[Django] #29303: non_atomic_requests decorator alters _non_atomic_requests attribute of original function

[Django]

#29303: non_atomic_requests decorator alters _non_atomic_requests attribute of
original function
-+-
   Reporter:  Alasdair   |  Owner:  nobody
  Nicol  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When calling `non_atomic_requests` with a function, it alters the
 `_non_atomic_requests` attribute of the original function.

 Here's an example:

 {{{
 from django.db import transaction

 @transaction.non_atomic_requests(using='default')
 def my_view(request):
 return HttpResponse('')

 assert my_view._non_atomic_requests == {'default'}  # passes

 wrapped_view = transaction.non_atomic_requests(using='other')

 assert wrapped_view._non_atomic_requests == {'default', 'other'}  # passes
 assert my_view._non_atomic_requests == {'default'}  # fails
 }}}

 I realise that this is a contrived example. It isn't an issue when
 `non_atomic_requests` is used as a decorator:

 {{{
 @transaction.non_atomic_requests(using='default')
 @transaction.non_atomic_requests(using='other')
 def my_view(request)
 return HttpResponse('')
 }}}

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

Re: [Django] #29302: Support for MySQL's (>=5.6.1) accurate spatial functions

[Django]

#29302: Support for MySQL's (>=5.6.1) accurate spatial functions
+--
 Reporter:  Shiv Baishya|Owner:  nobody
 Type:  New feature |   Status:  new
Component:  GIS |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  MySQL GEOS Spatial  | 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 Shiv Baishya:

Old description:

> MySQL >=5.6.1 support accurate spatial functions, a.k.a,
> [https://dev.mysql.com/doc/refman/5.6/en/spatial-function-reference.html
> ST_ functions]. Django 1.11 still uses MySQL's old MBR (minimum bounding
> rectangle) functions.
> \\
> I am willing to migrate my
> [https://github.com/shiviser/django/tree/1.9.2_ST_build patch for django
> 1.9.2] to django 1.11 and create a pull request.
> \\
> Here is an elaborated [https://www.percona.com/blog/2013/10/21/using-the-
> new-mysql-spatial-functions-5-6-for-geo-enabled-applications/ article] on
> the advantages of the new MySQL's **ST_ functions**.
> \\
> **Related tickets**
> * https://code.djangoproject.com/ticket/22423 (4 years old, is anyone
> working on this?)
> * https://code.djangoproject.com/ticket/27574

New description:

 MySQL >=5.6.1 support accurate spatial functions, a.k.a,
 [https://dev.mysql.com/doc/refman/5.6/en/spatial-function-reference.html
 ST_ functions]. Django 1.11 still uses MySQL's old MBR (minimum bounding
 rectangle) functions.
 \\
 I am willing to migrate
 [https://github.com/shiviser/django/tree/1.9.2_ST_build patch for django
 1.9.2] to django 1.11 and create a pull request.
 \\
 Here is an elaborated [https://www.percona.com/blog/2013/10/21/using-the-
 new-mysql-spatial-functions-5-6-for-geo-enabled-applications/ article] on
 the advantages of the new MySQL's **ST_ functions**.
 \\
 **Related tickets**
 * https://code.djangoproject.com/ticket/22423 (4 years old, is anyone
 working on this?)
 * https://code.djangoproject.com/ticket/27574

--

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

Re: [Django] #29302: Add support for MySQL's (>=5.6.1) ST_* spatial functions (was: Support for MySQL's (>=5.6.1) accurate spatial functions)

[Django]

#29302: Add support for MySQL's (>=5.6.1) ST_* spatial functions
+--
 Reporter:  Shiv Baishya|Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  GIS |  Version:  1.11
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  MySQL GEOS Spatial  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

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


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