Re: [Django] #33579: Raise a specialized exception when Model.save(update_fields) does not affect any rows

[Django]

#33579: Raise a specialized exception when Model.save(update_fields) does not
affect any rows
-+-
 Reporter:  Simon Charette   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  4.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
-+-
Description changed by Simon Charette:

Old description:

> When `Model.save(update_fields)` is used to update an instance of a
> previously fetched model and the resulting `UPDATE` doesn't affect any
> row a `DatabaseError`
> [https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L1000
> is raised].
>
> Since the resulting exception cannot be differentiated by its `type` from
> any other exception raised during `save` (e.g. a failed `UPDATE` also
> results in a `DatabaseError`) the only pattern to gracefully handle this
> rare edge case to catch all `DatabaseError` and compare its `.args[0]`
> (or `str` representation) to a string that doesn't offer any stability
> guarantees.
>
> In order to make it easier for advanced users that rely on the
> `update_fields` feature to handle this case differently from others where
> a `DatabaseError` is raised I propose that that we introduced a new
> `DatabaseError` subclass that would be raised instead when an unexpected
> empty update occurs.
>
> I believe
> [https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L997-L1000
> both instances] should be switched to this pattern (`force_update` and
> `update_fields`).

New description:

 When `Model.save(update_fields)` is used to update an instance of a
 previously fetched model and the resulting `UPDATE` doesn't affect any row
 a `DatabaseError`
 
[https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L1000
 is raised].

 Since the resulting exception cannot be differentiated by its `type` from
 any other dababase errors occuring during `save` (e.g. a failed `UPDATE`
 also results in a `DatabaseError`) the only pattern to gracefully handle
 this rare edge case to catch all `DatabaseError` and compare its
 `.args[0]` (or `str` representation) to a string that doesn't offer any
 stability guarantees.

 In order to make it easier for advanced users that rely on the
 `update_fields` feature to handle this case differently from others where
 a `DatabaseError` is raised I propose that that we introduce a new
 `DatabaseError` subclass that would be raised instead when an unexpected
 empty update occurs.

 I believe
 
[https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L997-L1000
 both instances] should be switched to this pattern (`force_update` and
 `update_fields`).

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f8f9e6ed7-d53123de-c35c-4fcc-81dc-588aac12d767-00%40eu-central-1.amazonses.com.

[Django] #33579: Raise a specialized exception when Model.save(update_fields) does not affect any rows

[Django]

#33579: Raise a specialized exception when Model.save(update_fields) does not
affect any rows
-+-
   Reporter:  Simon  |  Owner:  nobody
  Charette   |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  4.0
  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 `Model.save(update_fields)` is used to update an instance of a
 previously fetched model and the resulting `UPDATE` doesn't affect any row
 a `DatabaseError`
 
[https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L1000
 is raised].

 Since the resulting exception cannot be differentiated by its `type` from
 any other exception raised during `save` (e.g. a failed `UPDATE` also
 results in a `DatabaseError`) the only pattern to gracefully handle this
 rare edge case to catch all `DatabaseError` and compare its `.args[0]` (or
 `str` representation) to a string that doesn't offer any stability
 guarantees.

 In order to make it easier for advanced users that rely on the
 `update_fields` feature to handle this case differently from others where
 a `DatabaseError` is raised I propose that that we introduced a new
 `DatabaseError` subclass that would be raised instead when an unexpected
 empty update occurs.

 I believe
 
[https://github.com/django/django/blob/3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc/django/db/models/base.py#L997-L1000
 both instances] should be switched to this pattern (`force_update` and
 `update_fields`).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f8f9d36a8-fbb359ad-15fa-424f-a7cd-02871375e849-00%40eu-central-1.amazonses.com.

Re: [Django] #33533: SESSION_SAVE_EVERY_REQUEST = True does not handle parallel requests well if some scenarios

[Django]

#33533: SESSION_SAVE_EVERY_REQUEST = True does not handle parallel requests 
well if
some scenarios
--+--
 Reporter:  Michael   |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  contrib.sessions  |  Version:  4.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by Michael:

Old description:

> In my project, there are some methods on a custom user model that require
> the `request` to calculate certain values. This simple middleware does
> the trick:
>
> {{{
> class AttachRequestToUserMiddleware:
> """Adds the request to the user object, so session information can be
> looked
> up by the custom user model.
>
> Must come after
> django.contrib.auth.middleware.AuthenticationMiddleware which adds the
> user"""
>
> def __init__(self, get_response):
> self.get_response = get_response
>
> def __call__(self, request):
> request.user.request = request
> return self.get_response(request)
> }}}
>
> In production, when there are multiple workers running parrallel by
> uWSGI, if one has `SESSION_SAVE_EVERY_REQUEST = True`, then if one makes
> async requests from JavaScript (e.g. say a Service Worker caching pages
> on install), then the way it saves/retrieves sessions on every request
> fails in many spectacular ways.
>
> Here are some example trace backs:
> {{{
> Django Version: 4.0.1
> Python Version: 3.8.5
>
> Exception Type: ProgrammingError
> Exception Value:
> no results to fetch
> Exception Location: /home/michael/.venv/project/lib/python3.8/site-
> packages/django/db/utils.py, line 97, in inner
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/db/utils.py, line 97, in inner
> return func(*args, **kwargs)
>

> Exception Type: RuntimeError
> Exception Value:
> generator raised StopIteration
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/auth/__init__.py, line 60, in
> _get_user_session_key
> return get_user_model()._meta.pk.to_python(request.session[SESSION_KEY])
>
> Exception Type: MultipleObjectsReturned
> Exception Value:
> get() returned more than one Session -- it returned 2!
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/base.py, line 180, in
> _get_session
> return self._session_cache
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/core/handlers/exception.py, line 47, in inner
> response = get_response(request)
> ./core/accounts/middleware.py, line 33, in __call__
> request.user.request = request
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/utils/functional.py, line 278, in __setattr__
> self._setup()
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/utils/functional.py, line 384, in _setup
> self._wrapped = self._setupfunc()
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/auth/middleware.py, line 25, in 
> request.user = SimpleLazyObject(lambda: get_user(request))
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/auth/middleware.py, line 11, in get_user
> request._cached_user = auth.get_user(request)
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/auth/__init__.py, line 177, in get_user
> user_id = _get_user_session_key(request)
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/auth/__init__.py, line 60, in
> _get_user_session_key
> return
> get_user_model()._meta.pk.to_python(request.session[SESSION_KEY])
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/base.py, line 50, in
> __getitem__
> return self._session[key]
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/base.py, line 185, in
> _get_session
> self._session_cache = self.load()
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/db.py, line 43, in load
> s = self._get_session_from_db()
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/db.py, line 32, in
> _get_session_from_db
> return self.model.objects.get(
> /home/michael/.venv/project/lib/python3.8/site-
> packages/django/db/models/manager.py, line 85, in manager_method
> return getattr(self.get_queryset(), name)

Re: [Django] #33533: SESSION_SAVE_EVERY_REQUEST = True does not handle parallel requests well if some scenarios (was: Should it be impossible for a session dict to return more than one value for a key

[Django]

#33533: SESSION_SAVE_EVERY_REQUEST = True does not handle parallel requests 
well if
some scenarios
--+--
 Reporter:  Michael   |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  contrib.sessions  |  Version:  4.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

-- 
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/0107017f8f4cb901-0510cceb-0330-4f1e-93f1-8b09b4729475-00%40eu-central-1.amazonses.com.

Re: [Django] #33533: Should it be impossible for a session dict to return more than one value for a key?

[Django]

#33533: Should it be impossible for a session dict to return more than one value
for a key?
--+--
 Reporter:  Michael   |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  contrib.sessions  |  Version:  4.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Old description:

> In my project, I store the serial number of the device that logs in it's
> session. However in the code that gets the value from the session:
>
> {{{
> SESSION_SERIAL_NUMBER = 'terminal_serial_number'
>
> user._serial_number = request.session.get(SESSION_SERIAL_NUMBER, '')
> }}}
>
> Very occasionally throws an error. The part that baffles me is:
>
> > get() returned more than one Session -- it returned more than 20!
>
> How can a dict return more than one result, surely that is a bug for a
> dict to return more than one value?
>
> Note: When I query the database `django_sessions` table with the given
> `sessionid`, it only returns one row.
>
> Heres the error (from the email):
>
> {{{
> Internal Server Error: /accounts/login/
>
> ProgrammingError at /accounts/login/
> no results to fetch
> }}}
>
> And the traceback:
>
> {{{
> Traceback (most recent call last):
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/base.py", line 180, in
> _get_session
> return self._session_cache
>
> During handling of the above exception ('SessionStore' object has no
> attribute '_session_cache'), another exception occurred:
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/core/handlers/exception.py", line 47, in inner
> response = get_response(request)
>   File "./dist/terminals/middleware.py", line 11, in __call__
> user._serial_number = request.session.get(SESSION_SERIAL_NUMBER, '')
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/base.py", line 65, in get
> return self._session.get(key, default)
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/base.py", line 185, in
> _get_session
> self._session_cache = self.load()
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/db.py", line 43, in load
> s = self._get_session_from_db()
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/db.py", line 32, in
> _get_session_from_db
> return self.model.objects.get(
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/db/models/manager.py", line 85, in manager_method
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/db/models/query.py", line 443, in get
> raise self.model.MultipleObjectsReturned(
>
> During handling of the above exception (get() returned more than one
> Session -- it returned more than 20!), another exception occurred:
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/contrib/sessions/backends/base.py", line 180, in
> _get_session
> return self._session_cache
>
> During handling of the above exception ('SessionStore' object has no
> attribute '_session_cache'), another exception occurred:
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/db/utils.py", line 97, in inner
> return func(*args, **kwargs)
>
> The above exception (no results to fetch) was the direct cause of the
> following exception:
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/core/handlers/exception.py", line 47, in inner
> response = get_response(request)
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/utils/deprecation.py", line 126, in __call__
> response = response or self.get_response(request)
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/core/handlers/exception.py", line 49, in inner
> response = response_for_exception(request, exc)
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/core/handlers/exception.py", line 110, in
> response_for_exception
> response = handle_uncaught_exception(request,
> get_resolver(get_urlconf()), sys.exc_info())
>   File "/home/company/.venv/project/lib/python3.8/site-
> packages/django/core/handlers/exception.py", line 149, in
> handle_uncaught_exception
> return callback(request)
>   File "./core/base/views.py", line

Re: [Django] #31169: Allow parallel test runner to work with Windows/macOS `spawn` process start method.

[Django]

#31169: Allow parallel test runner to work with Windows/macOS `spawn` process 
start
method.
-+-
 Reporter:  Brandon Navra|Owner:  David
 |  Smith
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc" 3b3f38b]:
 {{{
 #!CommitTicketReference repository=""
 revision="3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc"
 Fixed #31169 -- Adapted the parallel test runner to use spawn.

 Co-authored-by: Valz 
 Co-authored-by: Nick Pope 
 }}}

-- 
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/0107017f8e2dfc5a-0cb7881c-63bb-43e1-9dce-87e27da98a37-00%40eu-central-1.amazonses.com.

Re: [Django] #33577: Confirm/Add support for GDAL 3.4.

[Django]

#33577: Confirm/Add support for GDAL 3.4.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15513 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/0107017f8e217983-77ea3577-5e90-4d77-b64e-4862a49c6b92-00%40eu-central-1.amazonses.com.

Re: [Django] #33578: How feasible is modifying the django.db.connections object at run time for a multitenant system which uses isolated databases for tenancy

[Django]

#33578: How feasible is modifying the django.db.connections object at run time 
for
a multitenant system which uses isolated databases for tenancy
-+-
 Reporter:  mukilr   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  dbrouter | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Creating a new database connection or modifying an existing one on fly is
 not supported.

-- 
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/0107017f8e0d0732-28e5b677-877d-4fd1-8939-1fb36333a6c7-00%40eu-central-1.amazonses.com.

Re: [Django] #33578: How feasible is modifying the django.db.connections object at run time for a multitenant system which uses isolated databases for tenancy

[Django]

#33578: How feasible is modifying the django.db.connections object at run time 
for
a multitenant system which uses isolated databases for tenancy
-+-
 Reporter:  Mukil Rajeev |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  dbrouter | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Trac is for bug reports only. Please see
 TicketClosingReasons/UseSupportChannels

-- 
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/0107017f8e0bf14b-81806cbf-adbc-4d19-ae61-57cbad6465e1-00%40eu-central-1.amazonses.com.

[Django] #33578: How feasible is modifying the django.db.connections object at run time for a multitenant system which uses isolated databases for tenancy

[Django]

#33578: How feasible is modifying the django.db.connections object at run time 
for
a multitenant system which uses isolated databases for tenancy
-+-
   Reporter:  mukilr |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  dbrouter
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have a FastAPI based application for which I am using the Django ORM to
 access the databases. And Im using the starlette-config dependency to
 manage the request context including the database details which will be
 part of the request.

 I am currently updating the django.db.connections.databases object on the
 fly in a FastAPI middleware as detailed here:
 https://stackoverflow.com/a/28891429/2324527

 After this, Im using a custom database router to select the newly added
 database for performing the database operation. Is this method feasible
 for production?

 If so, do we have a more streamlined approach that could be introduced so
 that django supports dynamic database switching on the fly?

-- 
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/0107017f8dfc56e7-952bf9b4-5e02-4400-81a3-9eadc16c-00%40eu-central-1.amazonses.com.

Re: [Django] #33256: Some schema tests don't clean up their tables

[Django]

#33256: Some schema tests don't clean up their tables
-+-
 Reporter:  Tim Graham   |Owner:  Mohammad
 Type:   |  Ali Mehdizadeh
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 The errors happen on a second consecutive test run (and don't remove the
 existing database between test runs).

-- 
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/0107017f8ddf22ff-4e28c0ff-99f5-4bc6-a665-607a2116a8f4-00%40eu-central-1.amazonses.com.

Re: [Django] #33256: Some schema tests don't clean up their tables

[Django]

#33256: Some schema tests don't clean up their tables
-+-
 Reporter:  Tim Graham   |Owner:  Mohammad
 Type:   |  Ali Mehdizadeh
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mohammad Ali Mehdizadeh):

 This is my test_postgres.py file:


 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'USER': 'postgres_user',
 'PASSWORD': 'postgres_password',
 'HOST': 'postgres_host',
 'PORT': 'postgres_port',
 },
 'other': {
 'ENGINE': 'django.db.backends.postgresql',
 'USER': 'postgres_user',
 'PASSWORD': 'postgres_password',
 'HOST': 'postgres_host',
 'PORT': 'postgres_port',
 },
 }

 SECRET_KEY = "django_tests_secret_key"

 # Use a fast hasher to speed up tests.
 PASSWORD_HASHERS = [
 "django.contrib.auth.hashers.MD5PasswordHasher",
 ]

 DEFAULT_AUTO_FIELD = "django.db.models.AutoField"

 USE_TZ = False
 }}}

-- 
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/0107017f8ddcc5b4-b9bc3831-2c25-4bbe-bf25-ec2e7ded203f-00%40eu-central-1.amazonses.com.

Re: [Django] #33256: Some schema tests don't clean up their tables

[Django]

#33256: Some schema tests don't clean up their tables
-+-
 Reporter:  Tim Graham   |Owner:  Mohammad
 Type:   |  Ali Mehdizadeh
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mohammad Ali Mehdizadeh):

 Replying to [comment:9 Tim Graham]:
 > Have you run the command a second time so that you're reusing an
 existing database?

 No, I use a new instance of postgres and I check the databases and remove
 ''test_'' database each time.
 But I can't produce errors.

-- 
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/0107017f8dd929ba-db3cdf5b-de2b-4b24-bb56-146d3366b13e-00%40eu-central-1.amazonses.com.

Re: [Django] #33577: Confirm/Add support for GDAL 3.4.

[Django]

#33577: Confirm/Add support for GDAL 3.4.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 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):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f8d9b94f1-9a04875c-a5ac-4ae8-9819-b7308e9a2640-00%40eu-central-1.amazonses.com.

Re: [Django] #33577: Confirm/Add support for GDAL 3.4.

[Django]

#33577: Confirm/Add support for GDAL 3.4.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 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 Mariusz Felisiak):

 * stage:  Accepted => Unreviewed


Old description:

> See release notes:
> - [https://github.com/OSGeo/gdal/blob/v3.4.0/gdal/NEWS.md 3.4.0]
> - [https://github.com/OSGeo/gdal/blob/v3.4.1/gdal/NEWS.md 3.4.1]
> - [https://github.com/OSGeo/gdal/blob/v3.4.2/gdal/NEWS.md 3.4.2]
>
> Some tests fail with GDAL 3.4+:
> - `gis_tests.gdal_tests.test_raster.GDALBandTests.test_band_data`
> - `gis_tests.inspectapp.tests.OGRInspectTest.test_time_field`
> -
> `gis_tests.gdal_tests.test_raster.GDALRasterTests.test_raster_info_accessor`

New description:

 See release notes:
 - [https://github.com/OSGeo/gdal/blob/v3.4.0/gdal/NEWS.md 3.4.0]
 - [https://github.com/OSGeo/gdal/blob/v3.4.1/gdal/NEWS.md 3.4.1]
 - [https://github.com/OSGeo/gdal/blob/v3.4.2/gdal/NEWS.md 3.4.2]

 Some tests fail with GDAL 3.4+:
 - `gis_tests.inspectapp.tests.OGRInspectTest.test_time_field` (3.4.0+)
 - `gis_tests.gdal_tests.test_raster.GDALBandTests.test_band_data` (3.4.1+)
 -
 `gis_tests.gdal_tests.test_raster.GDALRasterTests.test_raster_info_accessor`
 (3.4.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/0107017f8d9b2ec7-68f0e665-e2de-458f-b8ec-53239c9c1863-00%40eu-central-1.amazonses.com.

Re: [Django] #33577: Confirm/Add support for GDAL 3.4.

[Django]

#33577: Confirm/Add support for GDAL 3.4.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 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 David Smith):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f8d7d6f52-39b90c95-0c22-44ae-8a21-ce367272aa56-00%40eu-central-1.amazonses.com.

[Django] #33577: Confirm/Add support for GDAL 3.4.

[Django]

#33577: Confirm/Add support for GDAL 3.4.
-+-
   Reporter:  Mariusz|  Owner:  Mariusz Felisiak
  Felisiak   |
   Type:  New| Status:  assigned
  feature|
  Component:  GIS|Version:  dev
   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  |
-+-
 See release notes:
 - [https://github.com/OSGeo/gdal/blob/v3.4.0/gdal/NEWS.md 3.4.0]
 - [https://github.com/OSGeo/gdal/blob/v3.4.1/gdal/NEWS.md 3.4.1]
 - [https://github.com/OSGeo/gdal/blob/v3.4.2/gdal/NEWS.md 3.4.2]

 Some tests fail with GDAL 3.4+:
 - `gis_tests.gdal_tests.test_raster.GDALBandTests.test_band_data`
 - `gis_tests.inspectapp.tests.OGRInspectTest.test_time_field`
 -
 `gis_tests.gdal_tests.test_raster.GDALRasterTests.test_raster_info_accessor`

-- 
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/0107017f8d74c7c8-10a67e59-f592-4e12-9048-e86a7b104c02-00%40eu-central-1.amazonses.com.

Re: [Django] #33552: has_key, has_keys, and has_any_keys JSONField() lookups don't handle numeric keys on SQLite, MySQL, and Oracle.

[Django]

#33552: has_key, has_keys, and has_any_keys JSONField() lookups don't handle
numeric keys on SQLite, MySQL, and Oracle.
-+-
 Reporter:  TheTerrasque |Owner:  Sage
 |  Abdullah
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"a88fab1bca33c037bd1a12459c215d7bc1247735" a88fab1]:
 {{{
 #!CommitTicketReference repository=""
 revision="a88fab1bca33c037bd1a12459c215d7bc1247735"
 Fixed #33552 -- Fixed JSONField has key lookups with numeric keys on
 MariaDB, MySQL, Oracle, and SQLite.
 }}}

-- 
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/0107017f8c9a0551-b8127b10-472f-4c7b-914f-ecbd3f4b9e2c-00%40eu-central-1.amazonses.com.