Re: [Django] #32416: Apparent regression of #22414 from switching to ThreadedWSGIServer in LiveServerTestCase (#20238)

[Django]

#32416: Apparent regression of #22414 from switching to ThreadedWSGIServer in
LiveServerTestCase (#20238)
+--
 Reporter:  Chris Jerdonek  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  2.2
 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 Chris Jerdonek):

 Here is some more info I've collected. For each request, Django's
 `ThreadedWSGIServer` calls its `process_request()` method, which lives in
 CPython's `ThreadingMixIn`. In this method, `ThreadingMixIn` creates a new
 thread with `target=self.process_request_thread`. The
 `ThreadingMixIn.process_request_thread()` method looks like this:

 {{{#!python
 def process_request_thread(self, request, client_address):
 """Same as in BaseServer but as a thread.

 In addition, exception handling is done here.
 """
 try:
 self.finish_request(request, client_address)
 except Exception:
 self.handle_error(request, client_address)
 finally:
 self.shutdown_request(request)
 }}}

 The `shutdown_request()` method has its implementation inside CPython's
 `socketserver.TCPServer`. That method looks like this (`close_request()`
 is also included here):

 {{{#!python
 def shutdown_request(self, request):
 """Called to shutdown and close an individual request."""
 try:
 #explicitly shutdown.  socket.close() merely releases
 #the socket and waits for GC to perform the actual close.
 request.shutdown(socket.SHUT_WR)
 except OSError:
 pass #some platforms may raise ENOTCONN here
 self.close_request(request)

 def close_request(self, request):
 """Called to clean up an individual request."""
 request.close()
 }}}

 Thus, if we wanted, database connections could perhaps be closed inside
 `close_request()`. This could be done by adding a suitable implementation
 to `ThreadedWSGIServer`, thus overriding
 `socketserver.TCPServer.close_request()` .

 The thread-sharing needed for SQLite could probably also be handled by
 adding suitable method overrides to `ThreadedWSGIServer`.

 By the way, since `LiveServerThread` currently creates its server with a
 hard-coded class like this:

 {{{#!python
 def _create_server(self):
 return ThreadedWSGIServer((self.host, self.port),
 QuietWSGIRequestHandler, allow_reuse_address=False)
 }}}

 it would be easier for users if it instead got the class from a class
 attribute, e.g.

 {{{#!python
 def _create_server(self):
 return self.http_server_class((self.host, self.port),
 QuietWSGIRequestHandler, allow_reuse_address=False)
 }}}

 That would let people patch `ThreadedWSGIServer` more easily, if needed.
 This is similar to how `LiveServerTestCase` has a `server_thread_class`
 class attribute currently set to `LiveServerThread` (with the attribute
 added in #26976).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.349982e29ea5bcb0540e35d3e05d7908%40djangoproject.com.

Re: [Django] #32411: Case-insensitive lookups on JSONField doesn't work on MySQL.

[Django]

#32411: Case-insensitive lookups on JSONField doesn't work on MySQL.
-+-
 Reporter:  elonzh   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField mysql  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13979 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.2a1db21295b605a03ad487ce235ec9cc%40djangoproject.com.

Re: [Django] #32420: build_instance in (de)serializers uses model's primary key field name instead of attname to detect if data contains a primary key

[Django]

#32420: build_instance in (de)serializers uses model's primary key field name
instead of attname to detect if data contains a primary key
--+
 Reporter:  trybik|Owner:  trybik
 Type:  Bug   |   Status:  closed
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"8e90560aa8868a42bb8eda6273595bf0932a6090" 8e90560a]:
 {{{
 #!CommitTicketReference repository=""
 revision="8e90560aa8868a42bb8eda6273595bf0932a6090"
 Fixed #32420 -- Fixed detecting primary key values in deserialization when
 PK is also a FK.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ca5baa3287ef9b94010d152f31dac35c%40djangoproject.com.

Re: [Django] #32420: build_instance in (de)serializers uses model's primary key field name instead of attname to detect if data contains a primary key

[Django]

#32420: build_instance in (de)serializers uses model's primary key field name
instead of attname to detect if data contains a primary key
--+
 Reporter:  trybik|Owner:  trybik
 Type:  Bug   |   Status:  closed
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"d881a0ea3b733a64cfb5fe19561bb01479669ed6" d881a0ea]:
 {{{
 #!CommitTicketReference repository=""
 revision="d881a0ea3b733a64cfb5fe19561bb01479669ed6"
 [3.2.x] Fixed #32420 -- Fixed detecting primary key values in
 deserialization when PK is also a FK.

 Backport of 8e90560aa8868a42bb8eda6273595bf0932a6090 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.f2f0134b9dd239d8ddf2eae23ad7959f%40djangoproject.com.

Re: [Django] #32411: Case-insensitive lookups on JSONField doesn't work on MySQL.

[Django]

#32411: Case-insensitive lookups on JSONField doesn't work on MySQL.
-+-
 Reporter:  elonzh   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField mysql  | 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 Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

[Django] #32423: Support for extra related lookup definitions of a field.

[Django]

#32423: Support for extra related lookup definitions of a field.
-+-
   Reporter:  CloudCode  |  Owner:  nobody
  Hungary|
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  3.1
  layer (models, ORM)|   Keywords:  ForeignKey,
   Severity:  Normal |  ManyToOneRel
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When adding ForeignKeys to models one have the option to specify related
 name. It would be useful, to be able to specify multiple related names,
 and assign different queries for each of those. See the example below:

 There are products, with some master data, like SKU and some variations of
 that product in different contexts (profiles) like name and description.

 {{{
 class Product:
 sku = models.CharField()

 class ProductProfileGroup:
 is_default = models.BooleanField()

 class ProductProfile:
 group = models.ForeignKey(to='ProductProfileGroup',
 related_name='profiles')
 product = models.ForeignKey(to='Product', related_name='profiles')
 name = models.CharField()
 description = models.CharField()
 }}}


 If I were to retrieve all information of a product, with a specific
 profile group, I have to write the below code:
 {{{
 Product.objects.annotate(
 name=F('profiles__name'),
 description=F('profiles__description'),
 ).filter(profiles__group_id=1)

 """
 select product.sku, product_profile.name, product_profile.description
 from product
 join product_profile on product_profile.product_id = product.id
 where product_profile.group_id = 1
 """
 }}}

 This is a bit cumbersome, hard to read because of those plurals. My
 suggested approach would be something like:

 {{{
 def get_selected_profile():
 # maybe use settings, or some request context like
 https://pypi.org/project/django-currentuser/
 return
 
Q(product_profile_group_id=get_current_user().preferred_product_profile_group_id)

 class ProductProfile:
 product = models.ForeignKey(to='Product', related_name='profiles',
 related_queries={
 'default_profile': Q(is_default=True),
 'selected_profile': get_selected_profile,
 })

 # the same annotation, much more readable:
 Product.objects.annotate(
 name=F('default_profile__name'),
 )

 """
 select product.sku, product_profile.name, product_profile.description
 from product
 join product_profile on product_profile.product_id = product.id and
 product_profile.is_default is true
 """

 Product.objects.annotate(
 name=F('selected_profile__name'),
 )

 """
 select product.sku, product_profile.name, product_profile.description
 from product
 join product_profile on product_profile.product_id = product.id and
 product_profile.product_profile_group_id = 1
 """
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.8ba3ec7189064e46a626bdaee8b359b6%40djangoproject.com.

Re: [Django] #32419: "Serving files uploaded by a user during development" example unclear about "urls.py"

[Django]

#32419: "Serving files uploaded by a user during development" example unclear 
about
"urls.py"
-+-
 Reporter:  Josef Richter|Owner:  Amankumar
 Type:   |  Singh
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  media, uploads,  | Triage Stage:  Accepted
  images, forms, MEDIA_URL,  |
  MEDIA_ROOT, tutorial   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"51637222b6eeed81d9ce6f5d24e22e249c605ba3" 51637222]:
 {{{
 #!CommitTicketReference repository=""
 revision="51637222b6eeed81d9ce6f5d24e22e249c605ba3"
 Fixed #32419 -- Clarified URLconf in example of serving media files.
 }}}

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

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

Re: [Django] #32419: "Serving files uploaded by a user during development" example unclear about "urls.py"

[Django]

#32419: "Serving files uploaded by a user during development" example unclear 
about
"urls.py"
-+-
 Reporter:  Josef Richter|Owner:  Amankumar
 Type:   |  Singh
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  media, uploads,  | Triage Stage:  Accepted
  images, forms, MEDIA_URL,  |
  MEDIA_ROOT, tutorial   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Josef Richter):

 Replying to [comment:3 Tim Graham]:
 > It seems like a basic understanding of how the URL system works would
 get you to the right answer, but... would it be more clear to you if it
 said, "you can do this by adding the following snippet to your
 `ROOT_URLCONF`" (changing `urls.py` to `ROOT_URLCONF`). I don't think
 referencing the filenames in the tutorial here is a good idea.

 Yes, probably. I'm just saying it's an easy mistake to make for a beginner
 who sees Django for the first time in their life and don't know the
 details of its URL system, structuring the app, etc. And it's hard to
 identify and fix that mistake for a beginner.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.97732d77ce7a781d5f6ad93f485dc1f8%40djangoproject.com.

Re: [Django] #32419: "Serving files uploaded by a user during development" example unclear about "urls.py"

[Django]

#32419: "Serving files uploaded by a user during development" example unclear 
about
"urls.py"
-+-
 Reporter:  Josef Richter|Owner:  Amankumar
 Type:   |  Singh
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  media, uploads,  | Triage Stage:  Accepted
  images, forms, MEDIA_URL,  |
  MEDIA_ROOT, tutorial   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d192d751e15f0573c9ebb16cf5173ab9c3ae3801" d192d751]:
 {{{
 #!CommitTicketReference repository=""
 revision="d192d751e15f0573c9ebb16cf5173ab9c3ae3801"
 [3.2.x] Fixed #32419 -- Clarified URLconf in example of serving media
 files.

 Backport of 51637222b6eeed81d9ce6f5d24e22e249c605ba3 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.2465b3ff5d17dfd1d205f4efa73d7c7d%40djangoproject.com.

Re: [Django] #32416: Apparent regression of #22414 from switching to ThreadedWSGIServer in LiveServerTestCase (#20238)

[Django]

#32416: Apparent regression of #22414 from switching to ThreadedWSGIServer in
LiveServerTestCase (#20238)
---+
 Reporter:  Chris Jerdonek |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  2.2
 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 Simon Charette):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Testing framework
 * stage:  Unreviewed => Accepted


Comment:

 I haven't reproduced myself but accepting on the basis on the very
 detailed analysis.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7bb50b541d9ec42b107ce30ea1a6ff1d%40djangoproject.com.

[Django] #32424: in-memory test database does not work with multiprocessing.apply_async

[Django]

#32424: in-memory test database does not work with multiprocessing.apply_async
-+-
   Reporter:  Tata   |  Owner:  nobody
  Krushna Chaitanya  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  3.0
  layer (models, ORM)|   Keywords:  sqlite3, threading,
   Severity:  Normal |  tests
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,
 I am using Django 3.0 (On Ubuntu 18.04 installed using pip3). The below
 example works only with threading but not with
 multiprocessing.apply_async. Here is my sample, Looking at the Django code
 I have made sure that all requirements are met, I am using py3.6 and the
 sqlite3 version is also met.


 {{{
 $ python3 -c "from sqlite3 import dbapi2 as Database; print
 (Database.__name__, Database.sqlite_version_info)"

 sqlite3.dbapi2 (3, 22, 0)
 }}}


 {{{
 import os

 os.environ["DJANGO_SETTINGS_MODULE"] = "settings"
 import datetime, threading
 from multiprocessing import Pool

 # django  stuff
 import django

 django.setup()
 from polls.models import *
 from django.core.mail import mail_admins
 from django.test.utils import *
 from django.db import connection

 def create_object():
 print("Creating Poll")
 p = Question()
 p.question_text = "What's up doc ?"
 p.pub_date = datetime.date.today()
 p.save()
 print("Poll object saved. Id: %d" % p.id)


 MODULE = 1

 if __name__ == "__main__":
 setup_test_environment()
 old_db_name = "db.sqlite3"
 new_db_name = connection.creation.create_test_db(verbosity=1)
 print("New DATABASE:", new_db_name)
 if MODULE == 0:
 t = threading.Thread(target=create_object)
 t.start()
 t.join()
 elif MODULE == 1:
 with Pool(2) as p:
 p.apply_async(create_object)
 else:
 create_object()
 obj = Question.objects.get()
 print(obj.question_text)
 teardown_test_environment()
 connection.creation.destroy_test_db(old_db_name)
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.26ab55214da02a8899620ff630cb2b39%40djangoproject.com.

Re: [Django] #32424: in-memory test database does not work with multiprocessing.apply_async

[Django]

#32424: in-memory test database does not work with multiprocessing.apply_async
-+-
 Reporter:  Tata Krushna |Owner:  nobody
  Chaitanya  |
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, threading,  | Triage Stage:
  tests  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tata Krushna Chaitanya):

 Similar to https://code.djangoproject.com/ticket/12118 but with
 multiprocess.apply_async instead of normal threads.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.bfcf10bb45f97501b3ce2fcd18b01362%40djangoproject.com.

Re: [Django] #32411: Case-insensitive lookups on JSONField doesn't work on MySQL.

[Django]

#32411: Case-insensitive lookups on JSONField doesn't work on MySQL.
-+-
 Reporter:  elonzh   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  JSONField mysql  | 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"63d239db037f02d98b7771c90422840bbb4a319a" 63d239db]:
 {{{
 #!CommitTicketReference repository=""
 revision="63d239db037f02d98b7771c90422840bbb4a319a"
 Fixed #32411 -- Fixed __icontains lookup for JSONField on MySQL.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.c60007960665f1ed50465bea939e6488%40djangoproject.com.

Re: [Django] #32423: Support for extra related lookup definitions of a field.

[Django]

#32423: Support for extra related lookup definitions of a field.
-+-
 Reporter:  Bálint Balina|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  ForeignKey,  | Triage Stage:
  ManyToOneRel   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this report, however I don't a reason to add a new mechanism
 for this. For example, you can achieve the same with
 [https://docs.djangoproject.com/en/dev/topics/db/managers/#adding-extra-
 manager-methods extra methods in the manager].

 Also, you'll reach a wider audience if you write to the
 DevelopersMailingList about your ideas.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.65c01f91a584c07e82cad7799cfbe012%40djangoproject.com.

Re: [Django] #32416: Apparent regression of #22414 from switching to ThreadedWSGIServer in LiveServerTestCase (#20238)

[Django]

#32416: Apparent regression of #22414 from switching to ThreadedWSGIServer in
LiveServerTestCase (#20238)
---+
 Reporter:  Chris Jerdonek |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  2.2
 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 Chris Jerdonek):

 FYI, I see that the lack of the SQLite thread-sharing logic I mentioned
 above has previously been reported here: #29062 (but without a root cause
 analysis / proposed fix). I will let that issue know my findings here.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8f9ff3a100e664ff3a0085b1d5f4e3d0%40djangoproject.com.

Re: [Django] #29062: "database table locked errors" when using sqlite in-memory database with LiveServerTestCase

[Django]

#29062: "database table locked errors" when using sqlite in-memory database with
LiveServerTestCase
-+-
 Reporter:  Juozas Masiulis  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, testing, | Triage Stage:  Accepted
  databases  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 FYI, yesterday I found and described the root cause of this issue on
 #32416. (There I was interested in a different issue that affected non-
 SQLite databases, though, namely database connections not being closed
 when `LiveServerTestCase` is used with the new threading behavior.)

 If you read my first comments on that issue, you can see that a possible
 fix is to define suitable method overrides in `ThreadedWSGIServer`.
 Basically the same SQLite-specific connection-sharing logic that
 `LiveServerTestCase.LiveServerThread()` and `LiveServerThread.run()` have
 needs to be added to `ThreadedWSGIServer`. The `LiveServerTestCase` and
 `LiveServerThread` logic can be found more or less here:
 
https://github.com/django/django/blob/63d239db037f02d98b7771c90422840bbb4a319a/django/test/testcases.py#L1524-L1537
 
https://github.com/django/django/blob/63d239db037f02d98b7771c90422840bbb4a319a/django/test/testcases.py#L1465-L1469

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.9731d7568e40036234998c4bb4870cad%40djangoproject.com.

Re: [Django] #32424: in-memory test database does not work with multiprocessing.apply_async

[Django]

#32424: in-memory test database does not work with multiprocessing.apply_async
-+-
 Reporter:  Tata Krushna |Owner:
  Chaitanya  |  ArkaprabhaChakraborty
 Type:  Uncategorized|   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, threading,  | Triage Stage:
  tests  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ArkaprabhaChakraborty):

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


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.79bd41ab4ef523f338b1e98826ca0a65%40djangoproject.com.

Re: [Django] #32417: LiveServerTestCase's tearDownClass() not symmetric with setUpClass()

[Django]

#32417: LiveServerTestCase's tearDownClass() not symmetric with setUpClass()
+--
 Reporter:  Chris Jerdonek  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  2.2
 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 Chris Jerdonek):

 After looking at this some more, rather than keeping the symmetry, it
 looks like the first three lines of
 `LiveServerTestCase._tearDownClassInternal` can simply be deleted:

 {{{#!python
 @classmethod
 def _tearDownClassInternal(cls):
 # There may not be a 'server_thread' attribute if setUpClass() for
 some
 # reasons has raised an exception.
 if hasattr(cls, 'server_thread'):
 }}}

 This is because it doesn't seem like it's possible for
 `_tearDownClassInternal()` to be called without `server_thread` being set.
 For example, per the [https://docs.python.org/3/library/unittest.html
 #setupclass-and-teardownclass Python unittest docs], `tearDownClass()`
 isn't called if `setUpClass()` errors out:

 > If an exception is raised during a setUpClass then the tests in the
 class are not run and the tearDownClass is not run.

 Also, `LiveServerTestCase.setUpClass()` only calls
 `_tearDownClassInternal()` when `cls.server_thread` is already set.

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

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

Re: [Django] #32417: LiveServerTestCase._tearDownClassInternal has unneeded hasattr check (was: LiveServerTestCase's tearDownClass() not symmetric with setUpClass())

[Django]

#32417: LiveServerTestCase._tearDownClassInternal has unneeded hasattr check
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Testing framework


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

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

Re: [Django] #32417: LiveServerTestCase._tearDownClassInternal() has unneeded hasattr check (was: LiveServerTestCase._tearDownClassInternal has unneeded hasattr check)

[Django]

#32417: LiveServerTestCase._tearDownClassInternal() has unneeded hasattr check
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  2.2
 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 Mariusz Felisiak):

 * cc: Jon Dufresne (added)
 * stage:  Unreviewed => Accepted


Comment:

 Looks reasonable.

 `staticfiles_tests.test_liveserver.StaticLiveServerChecks.test_test_test`
 fails with this change, but as far as I'm aware removing
 `cls.server_thread` is only a way to avoid `_tearDownClassInternal()`
 call, so we can override it instead, e.g.:
 {{{
 diff --git a/tests/staticfiles_tests/test_liveserver.py
 b/tests/staticfiles_tests/test_liveserver.py
 index 820fa5bc89..22c4a645e7 100644
 --- a/tests/staticfiles_tests/test_liveserver.py
 +++ b/tests/staticfiles_tests/test_liveserver.py
 @@ -54,6 +54,10 @@ class StaticLiveServerChecks(LiveServerBase):
  # skip it, as setUpClass doesn't call its parent either
  pass

 +@classmethod
 +def _tearDownClassInternal(cls):
 +pass
 +
  @classmethod
  def raises_exception(cls):
  try:
 @@ -64,9 +68,6 @@ class StaticLiveServerChecks(LiveServerBase):
  # app without having set the required STATIC_URL setting.")
  pass
  finally:
 -# Use del to avoid decrementing the database thread sharing
 count a
 -# second time.
 -del cls.server_thread
  super().tearDownClass()

  def test_test_test(self):

 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.3d89962969b6342627b23ac5203e38dc%40djangoproject.com.

Re: [Django] #32417: LiveServerTestCase._tearDownClassInternal() has unneeded hasattr check

[Django]

#32417: LiveServerTestCase._tearDownClassInternal() has unneeded hasattr check
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  2.2
 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 Chris Jerdonek):

 Are you sure that `super().tearDownClass()` needs to be called in that
 `finally` block? Maybe it only needs to be called in the case that
 `setUpClass()` raises an exception (because otherwise, `tearDownClass()`
 will be called automatically by `unittest`). Maybe that explains why
 something is getting called twice when it shouldn't.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.08adb97f2f94cc0c0db7700ac4fb0593%40djangoproject.com.

Re: [Django] #32416: LiveServerTestCase's ThreadedWSGIServer doesn't close database connections after each thread (was: Apparent regression of #22414 from switching to ThreadedWSGIServer in LiveServer

[Django]

#32416: LiveServerTestCase's ThreadedWSGIServer doesn't close database 
connections
after each thread
---+
 Reporter:  Chris Jerdonek |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  2.2
 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
---+

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1234866a531faeb5199c91cb555ca15f%40djangoproject.com.