date:20200917

Re: [Django] #32015: psycopg2 jsonb is not loaded with connections.cursor (was: BUG: psycopg2 json is not loaded with connections.cursor)

2020-09-17 Thread Django

#32015: psycopg2 jsonb is not loaded with connections.cursor
-+-
 Reporter:  Matt Buck|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  psycopg2, database,  | Triage Stage:
  postgresql, json, jsonb,   |  Unreviewed
  jsonfield  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Old description:

> Since the upgrade from v3->v3.1, I discovered this regression in the
> psycopg2 cursor.  jsonb results from sql queries are not loaded into
> python data structures.  This causes issues when dumping and loading
> again, the json fields do not get loaded on the front.  The offending
> line of code can be found here
> https://github.com/django/django/blob/master/django/db/backends/postgresql/base.py#L206
> in the postgresql backend.
>
> This code was introduced to work around issues with specifying a
> JSONDecoder in the new JSONField.  Attempting to implement a workaround
> by creating additional connections sort of works, but causes freezing
> during cleanup of test cases, and maybe more serious issues elsewhere.
>
> This is also causing issues with a ValuesQuerySet, the output from jsonb
> fields is always string.

New description:

 Since the upgrade from v3->v3.1, I discovered this regression in the
 psycopg2 cursor.  jsonb results from sql queries are not loaded into
 python data structures.  This causes issues when dumping and loading
 again, the json fields do not get loaded on the front.  The offending line
 of code can be found here
 
https://github.com/django/django/blob/master/django/db/backends/postgresql/base.py#L206
 in the postgresql backend.

 This code was introduced to work around issues with specifying a
 JSONDecoder in the new JSONField.  Attempting to implement a workaround by
 creating additional connections sort of works, but causes freezing during
 cleanup of test cases, and maybe more serious issues elsewhere.

 This is also causing issues with a ValuesQuerySet, the output from jsonb
 fields is always string.

--

Comment:

 > Since the upgrade from v3->v3.1, I discovered this regression in the
 psycopg2 cursor.  jsonb results from sql queries are not loaded into
 python data structures.

 This is an intended change, see #31991.

 > This causes issues when dumping and loading again, the json fields do
 not get loaded on the front.

 I cannot reproduce any issue with `dumpdata`/`loaddata`.

 > This is also causing issues with a ValuesQuerySet, the output from jsonb
 fields is always string.

 Using `QuerySet.values()` works for me.


 Duplicate of #31991. I'm happy to reopen if you can provide a sample
 project that reproduce described issues with builtin mechanisms.

-- 
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/065.a65d63f29512105922eb91b0b2dc365a%40djangoproject.com.

Re: [Django] #32016: mail_admins handler cannot be configured. (was: ValueError: Unable to configure handler 'mail_admins' on custom logging configuration)

2020-09-17 Thread Django

#32016: mail_admins handler cannot be configured.
-+-
 Reporter:  Susana Cárdenas  |Owner:  (none)
  Molinar|
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  3.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  settings, logging| 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):

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


Comment:

 Thanks for this ticket, however this configuration works for me with
 Django 3.1. Can you provide a small project that reproduces the issue?
 (without unrelated handlers, loggers, etc.).

-- 
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.250f7796f2aa9525a59b135d78fc275b%40djangoproject.com.

Re: [Django] #32005: Allow disabling of auto-404-redirection in LocaleMiddleware

2020-09-17 Thread Django

#32005: Allow disabling of auto-404-redirection in LocaleMiddleware
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  wontfix
 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:

> This is related to the last two comments on #17734.  Specifically, if an
> application decides to return an explicit 404, there is no way to prevent
> the LocaleMiddleware from overriding this and trying the language
> redirect.
>
> In those comments, it was about catch-all URL patterns.  I'm running into
> something related, but slightly different -- we
> [https://github.com/zulip/zulip/blob/master/zerver/middleware.py#L434
> serve 404's for the `/` endpoint if the subdomain isn't valid], which the
> LocaleMiddleware unhelpfully redirects to (e.g.) `/en/` which isn't any
> less of a 404.
>
> Would folks be amenable to a patch which disabled the auto-404-redirect
> functionality in the middleware with a flag of some sort?

New description:

 This is related to the last two comments on #17734.  Specifically, if an
 application decides to return an explicit 404, there is no way to prevent
 the LocaleMiddleware from overriding this and trying the language
 redirect.

 In those comments, it was about catch-all URL patterns.  I'm running into
 something related, but slightly different -- we
 
[https://github.com/zulip/zulip/blob/536bd3188e9428993fd712ed2f0df7c160b6ad60/zerver/middleware.py#L453
 serve 404's for the `/` endpoint if the subdomain isn't valid], which the
 LocaleMiddleware unhelpfully redirects to (e.g.) `/en/` which isn't any
 less of a 404.

 Would folks be amenable to a patch which disabled the auto-404-redirect
 functionality in the middleware with a flag of some sort?

--

Comment (by Alex Vandiver):

 Fair enough.  The only slight ugliness with subclassing is that one needs
 to repeat
 
[https://github.com/django/django/blob/master/django/middleware/locale.py#L58-L60
 the logic that adds `Content-Language` and `Vary` headers] -- skipping all
 of the `process_response` on 404s wouldn't produce the right headers.
 Which actually means a
 
[https://github.com/zulip/zulip/blob/536bd3188e9428993fd712ed2f0df7c160b6ad60/zerver/middleware.py#L378-L385
 reasonable amount of code duplication].

-- 
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.2d65cade9a025f259013eecaed816d29%40djangoproject.com.

[Django] #32016: ValueError: Unable to configure handler 'mail_admins' on custom logging configuration

2020-09-17 Thread Django

#32016: ValueError: Unable to configure handler 'mail_admins' on custom logging
configuration
-+-
   Reporter:  Susana |  Owner:  (none)
  Cárdenas Molinar   |
   Type:  Bug| Status:  new
  Component:  Error  |Version:  3.1
  reporting  |
   Severity:  Normal |   Keywords:  settings, logging
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When upgrading to Django 3.1, the following error appears when trying to
 start the application on Docker:

 `ValueError: Unable to configure handler 'mail_admins'`.

 The `mail_admins` section of the configuration is the same as the
 
[https://docs.djangoproject.com/en/3.1/topics/logging/#django.utils.log.AdminEmailHandler
 examples] shown in the documentation. This same code is working fine in
 Django 3.0 and when the `mail_admins` key is commented or deleted from the
 configuration, everything works properly.

 This is some of the code contained in the base settings file:

 {{{
 DJANGO_EMAIL_ADMINS_BACKEND = os.environ.get(
 "DJANGO_EMAIL_ADMINS_BACKEND",
 "django.core.mail.backends.console.EmailBackend"
 )
 LOGGING_CONFIG = None

 logging.config.dictConfig(
 {
 "version": 1,
 "disable_existing_loggers": False,
 "filters": {
 "require_debug_false": {"()":
 "django.utils.log.RequireDebugFalse"},
 "require_debug_true": {"()":
 "django.utils.log.RequireDebugTrue"},
 },
 "formatters": {
 "django.server": {
 "()": "django.utils.log.ServerFormatter",
 "format": "[%(server_time)s] %(message)s",
 }
 },
 "handlers": {
 "nodebug_console": {
 "level": "WARNING",
 "filters": ["require_debug_false"],
 "class": "logging.StreamHandler",
 },
 "debug_console": {
 "level": "INFO",
 "filters": ["require_debug_true"],
 "class": "logging.StreamHandler",
 },
 "django.server": {
 "level": "INFO",
 "class": "logging.StreamHandler",
 "formatter": "django.server",
 },
 "mail_admins": {
 "level": "ERROR",
 "filters": ["require_debug_false"],
 "class": "django.utils.log.AdminEmailHandler",
 "email_backend": DJANGO_EMAIL_ADMINS_BACKEND,
 },
 },
 "loggers": {
 "django": {
 "handlers": ["nodebug_console", "debug_console",
 "mail_admins"],
 "level": os.environ.get("DJANGO_LOG_LEVEL", "INFO"),
 },
 "django.server": {
 "handlers": ["django.server"],
 "level": os.environ.get("DJANGO_LOG_LEVEL", "INFO"),
 "propagate": False,
 },
 "Wikilink": {
 "handlers": ["nodebug_console", "debug_console",
 "mail_admins"],
 "level": os.environ.get("DJANGO_LOG_LEVEL", "INFO"),
 },
 },
 }
 )
 }}}

-- 
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.545eb54e400c6ff0dff22f07967e43d7%40djangoproject.com.

[Django] #32015: BUG: psycopg2 json is not loaded with connections.cursor

2020-09-17 Thread Django

#32015: BUG: psycopg2 json is not loaded with connections.cursor
-+-
Reporter: mblance| Owner: nobody
Type: | Status: new
Uncategorized |
Component: |Version: 3.1
Uncategorized | Keywords: psycopg2, database,
Severity: Normal | postgresql, json, jsonb, jsonfield
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
Since the upgrade from v3->v3.1, I discovered this regression in the
psycopg2 cursor. jsonb results from sql queries are not loaded into
python data structures. This causes issues when dumping and loading
again, the json fields do not get loaded on the front. The offending line
of code can be found here

https://github.com/django/django/blob/master/django/db/backends/postgresql/base.py#L206
in the postgresql backend.

This code was introduced to work around issues with specifying a
JSONDecoder in the new JSONField. Attempting to implement a workaround by
creating additional connections sort of works, but causes freezing during
cleanup of test cases, and maybe more serious issues elsewhere.

--
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/050.0ee86cefa55b6ad78cc3651aafc5e8f9%40djangoproject.com.

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

2020-09-17 Thread Django

#31880: QuerySet.aggregate() mixes annotated fields names.
-+-
 Reporter:  Thodoris |Owner:  David
  Sotiropoulos   |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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
-+-

Comment (by Simon Charette):

 I think raising an explicit error at the ORM level is the right call for
 now. Nothing prevents us from eventually fixing this if we can align on an
 expected behaviour in the future but users will get a clearer error
 message in the mean 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.4deb8f26843c64c7a0ad194eac0a124a%40djangoproject.com.

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

2020-09-17 Thread Django

* has_patch: 0 => 1

Comment:

Hi, thanks for taking the time diving into the issue.

I agree that the expected behaviour is not obvious.
My reflection why it could be supported was that:
* it is possible since the aliases are used in two different queries (the
outer and the inner) in the case of an aggregation
* ''You can always use different aliases.'' it's true, but with a system
that automatically generates QuerySets it might not be easy to "just use
different aliases".

However, let's go with an error, I agree that it adds complexity for not a
lot of added value. There is a fair chance that the first patch missed
edge cases.
I pushed a new patch: https://github.com/django/django/pull/13431

Happy to hear what you think about this one :)

--
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/066.836a555374bf4d4c8569876cfe924bfa%40djangoproject.com.

Re: [Django] #20516: Allow use of prepared statements

2020-09-17 Thread Django

#20516: Allow use of prepared statements
-+-
 Reporter:  est  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db, prepared | Triage Stage:  Accepted
  statement  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jeongsoo, Park):

 * cc: Jeongsoo, Park (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.524887b4655a4961d996be19b4a29d87%40djangoproject.com.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

2020-09-17 Thread Django

#32013: Field choice attribute returns different objects in forms.
---+--
 Reporter:  Jaap Roes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  3.1
 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
---+--

Comment (by Carlton Gibson):

 > Should I go and wrap things in a ModelChoiceIteratorValue just to be
 sure?

 I wouldn't :)

 Choices are pretty much only cast to strings (for rendering)… like maybe
 there's some other case but it's not coming to mind easily… (and there are
 a mountain of tests around the form layer…)

 At this point I'd rather look at concrete issues that come up that worry
 about things that ''might'' break.

-- 
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/063.d35440a271fc0cc0d970f16501384be0%40djangoproject.com.

Re: [Django] #28939: Document which ORM methods provide an instance hint to database routers

2020-09-17 Thread Django

#28939: Document which ORM methods provide an instance hint to database routers
-+-
 Reporter:  Nick Pope|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch,| Triage Stage:  Accepted
  prefetch_related, using,   |
  connection |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"17a408207800ec3ceaf9c29fbb2c42629fd0ff76" 17a40820]:
 {{{
 #!CommitTicketReference repository=""
 revision="17a408207800ec3ceaf9c29fbb2c42629fd0ff76"
 [3.1.x] Refs #28939 -- Doc’d Prefetch behavior with multiple DBs.

 Backport of 8c0794ba0da2b5d668a7eb1c167e54beb7f40890 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/065.6dc38ddb94430af7840d2ba7e67c95a2%40djangoproject.com.

Re: [Django] #28939: Document which ORM methods provide an instance hint to database routers

2020-09-17 Thread Django

#28939: Document which ORM methods provide an instance hint to database routers
-+-
 Reporter:  Nick Pope|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch,| Triage Stage:  Accepted
  prefetch_related, using,   |
  connection |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"8c0794ba0da2b5d668a7eb1c167e54beb7f40890" 8c0794ba]:
 {{{
 #!CommitTicketReference repository=""
 revision="8c0794ba0da2b5d668a7eb1c167e54beb7f40890"
 Refs #28939 -- Doc’d Prefetch behavior with multiple DBs.
 }}}

-- 
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/065.f73f4c712a16cf6c6eb756deeed530f0%40djangoproject.com.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

2020-09-17 Thread Django

Comment (by Jaap Roes):

Replying to [comment:8 Carlton Gibson]:
> Hi Jaap. In normal cases I would expect manually setting choices to work
just fine, since we proxy `__str__` to the underlying object. The
filtering cases are interesting but a `.value` would resolve the more
esoteric ones.

I did some further manual testing and checking and can confirm everything
else seems to work fine. Is Django itself not depending on the first item
of the choices tuple being a `ModelChoiceIteratorValue` instance?

Since in some cases the entire choices attribute is set to a list of
`[(pk, str), ...]` I can imagine at some point code internal to Django
breaking as the first item doesn't have a `.value` or `.instance`
attribute. It doesn't seem to break *yet*, but it might? Should I go and
wrap things in a `ModelChoiceIteratorValue` just to be sure?

--
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/063.5bfec7cfe6d92436a733b3074b606a4a%40djangoproject.com.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

2020-09-17 Thread Django

#32013: Field choice attribute returns different objects in forms.
---+--
 Reporter:  Jaap Roes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  3.1
 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
---+--

Comment (by Carlton Gibson):

 Hi Jaap. In normal cases I would expect manually setting choices to work
 just fine, since we proxy `__str__`  to the underlying object. The
 filtering cases are interesting but a `.value` would resolve the more
 esoteric ones.

-- 
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/063.dec0128e8e809cfe5b37f1f4f89c2fa8%40djangoproject.com.

Re: [Django] #32014: When Upgrading Django1.11 to Django latest

2020-09-17 Thread Django

#32014: When Upgrading Django1.11 to Django latest
-+-
 Reporter:  Abishek Rajagopal|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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
-+-
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => invalid
 * easy:  1 => 0
 * severity:  Release blocker => Normal


Old description:

> After Installing the Latest Django version
> it asked me to upgrade Mysql clent as well
> like
>
> ""
> File "/usr/lib/python3.6/site-packages/django/db/backends/mysql/base.py",
> line 36, in 
> raise ImproperlyConfigured('mysqlclient 1.3.13 or newer is required;
> you have %s.' % Database.__version__)
> django.core.exceptions.ImproperlyConfigured: mysqlclient 1.3.13 or newer
> is required; you have 0.7.11.None.
>
> ""
>
> I installed latest version by pip install mysqlclient
>
> then im gettion this error,
>
> Collecting mysqlclient
>   Using cached
> https://files.pythonhosted.org/packages/a5/e1/e5f2b231c05dc51d9d87fa5066f90d1405345c54b14b0b11a1c859020f21/mysqlclient-2.0.1.tar.gz
> Complete output from command python setup.py egg_info:
> /bin/sh: mysql_config: command not found
> /bin/sh: mariadb_config: command not found
> /bin/sh: mysql_config: command not found
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/pip-build-0uh58twu/mysqlclient/setup.py", line 15, in
> 
> metadata, options = get_config()
>   File "/tmp/pip-build-0uh58twu/mysqlclient/setup_posix.py", line 65,
> in get_config
> libs = mysql_config("libs")
>   File "/tmp/pip-build-0uh58twu/mysqlclient/setup_posix.py", line 31,
> in mysql_config
> raise OSError("{} not found".format(_mysql_config_path))
> OSError: mysql_config not found
>

> Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-
> build-0uh58twu/mysqlclient/
>

> pls help

New description:

 After Installing the Latest Django version
 it asked me to upgrade Mysql clent as well
 like

 {{{
 File "/usr/lib/python3.6/site-packages/django/db/backends/mysql/base.py",
 line 36, in 
 raise ImproperlyConfigured('mysqlclient 1.3.13 or newer is required;
 you have %s.' % Database.__version__)
 django.core.exceptions.ImproperlyConfigured: mysqlclient 1.3.13 or newer
 is required; you have 0.7.11.None.
 }}}

 I installed latest version by pip install mysqlclient

 then im gettion this error,
 {{{
 Collecting mysqlclient
   Using cached
 
https://files.pythonhosted.org/packages/a5/e1/e5f2b231c05dc51d9d87fa5066f90d1405345c54b14b0b11a1c859020f21/mysqlclient-2.0.1.tar.gz
 Complete output from command python setup.py egg_info:
 /bin/sh: mysql_config: command not found
 /bin/sh: mariadb_config: command not found
 /bin/sh: mysql_config: command not found
 Traceback (most recent call last):
   File "", line 1, in 
   File "/tmp/pip-build-0uh58twu/mysqlclient/setup.py", line 15, in
 
 metadata, options = get_config()
   File "/tmp/pip-build-0uh58twu/mysqlclient/setup_posix.py", line 65,
 in get_config
 libs = mysql_config("libs")
   File "/tmp/pip-build-0uh58twu/mysqlclient/setup_posix.py", line 31,
 in mysql_config
 raise OSError("{} not found".format(_mysql_config_path))
 OSError: mysql_config not found
 }}}

 Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-
 build-0uh58twu/mysqlclient/


 pls help

--

Comment:

 Please don't use Trac as a support channel. Also you have an issue with
 `mysqlclient` not with Django.

-- 
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/083.ee12f3db399ee4cd04b350acee738b70%40djangoproject.com.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

2020-09-17 Thread Django

Comment (by Jaap Roes):

Replying to [comment:5 felixxm]:

> [...] Also, as far as I'm aware overriding `choices` for
`forms.ModelMultipleChoiceField` and `forms.ModelChoiceField` is not a
documented pattern I would rather override `.queryset`, see
[https://docs.djangoproject.com/en/3.1/ref/forms/fields/#fields-which-
handle-relationships Fields which handle relationship].

Sure, but this pattern is commonly used and I've seen it been recommended
on StackOverflow on several occasions. I'll investigate further and check
if nothing breaks here. This codebase is over 10 years old and not always
written by expert Django developers, so it's not unexpected for anti-
patterns to show up.

> > Or should we audit the entire codebase to see this new
ModelChoiceIteratorValue will break stuff?
>
> Yes, you should always audit your code when you bump multiple releases.

I'm only bumping a single release here. The migration from 1.4 to 3.0 has
been completed months ago and came with it's own trials and tribulations.
I wasn't expecting such breakage from bumping to 3.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/063.16a2b7ad395f7859e12fcc53b57ea59a%40djangoproject.com.

[Django] #32014: When Upgrading Django1.11 to Django latest

2020-09-17 Thread Django

#32014: When Upgrading Django1.11 to Django latest
-+-
   Reporter:  Abishek|  Owner:  nobody
  Rajagopal  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 After Installing the Latest Django version
 it asked me to upgrade Mysql clent as well
 like

 ""
 File "/usr/lib/python3.6/site-packages/django/db/backends/mysql/base.py",
 line 36, in 
 raise ImproperlyConfigured('mysqlclient 1.3.13 or newer is required;
 you have %s.' % Database.__version__)
 django.core.exceptions.ImproperlyConfigured: mysqlclient 1.3.13 or newer
 is required; you have 0.7.11.None.

 ""

 I installed latest version by pip install mysqlclient

 then im gettion this error,

 Collecting mysqlclient
   Using cached
 
https://files.pythonhosted.org/packages/a5/e1/e5f2b231c05dc51d9d87fa5066f90d1405345c54b14b0b11a1c859020f21/mysqlclient-2.0.1.tar.gz
 Complete output from command python setup.py egg_info:
 /bin/sh: mysql_config: command not found
 /bin/sh: mariadb_config: command not found
 /bin/sh: mysql_config: command not found
 Traceback (most recent call last):
   File "", line 1, in 
   File "/tmp/pip-build-0uh58twu/mysqlclient/setup.py", line 15, in
 
 metadata, options = get_config()
   File "/tmp/pip-build-0uh58twu/mysqlclient/setup_posix.py", line 65,
 in get_config
 libs = mysql_config("libs")
   File "/tmp/pip-build-0uh58twu/mysqlclient/setup_posix.py", line 31,
 in mysql_config
 raise OSError("{} not found".format(_mysql_config_path))
 OSError: mysql_config not found


 Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-
 build-0uh58twu/mysqlclient/


 pls help

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

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

Re: [Django] #32013: Field choice attribute returns different objects in forms.

2020-09-17 Thread Django

#32013: Field choice attribute returns different objects in forms.
---+--
 Reporter:  Jaap Roes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  3.1
 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
---+--

Comment (by felixxm):

 [https://github.com/django/django/pull/13430 PR with backward
 incompatibility note].

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

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

Re: [Django] #32013: Field choice attribute returns different objects in forms.

2020-09-17 Thread Django

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

Comment:

I closed it because we will not revert
67ea35df52f2e29bafca8881e4f356934061644e and we can add small backwards
incompatible note that `Refs` to this ticket.

> Our tests don't complain, but that might just be because we're not
covering/asserting deep enough.

It shouldn't be bad because `ModelChoiceIteratorValue` defines `__eq__()`
which compares `value`. Also, as far as I'm aware overriding `choices` for
`forms.ModelMultipleChoiceField` and `forms.ModelChoiceField` is not a
documented pattern I would rather override `.queryset`, see
[https://docs.djangoproject.com/en/3.1/ref/forms/fields/#fields-which-
handle-relationships Fields which handle relationship].

> Or should we audit the entire codebase to see this new
ModelChoiceIteratorValue will break stuff?

Yes, you should always audit your code when you bump multiple releases.

--
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/063.c0257ff5ea15bdecd8f27bf2cf6324a2%40djangoproject.com.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

2020-09-17 Thread Django

#32013: Field choice attribute returns different objects in forms.
---+--
 Reporter:  Jaap Roes  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  3.1
 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 Jaap Roes):

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


Comment:

 I'm left wondering if other places that manipulate `field.choices` will
 start breaking in unexpected ways.

 There's several instances of things like:

 {{{
 form.fields["category"].choices = [(pk, label) for pk, label in
 form.fields["category"].choices if pk == line.get_category().pk]
 }}}

 and

 {{{
 self.fields["realm"].choices = [(k, v) for (k, v) in
 self.fields["realm"].choices if str(k) != str(self.exclude.pk)]
 }}}

 or

 {{{
 self.fields["matter"].choices += [(self.data["matter"],
 str(Matter.objects.get(pk=self.data["matter"], realm=self.realm)),)]
 }}}

 Our tests don't complain, but that might just be because we're not
 covering/asserting deep enough. Can you confirm this code (and other code
 that manipulates / works with choices) will remain functional? Or should
 we audit the entire codebase to see this new `ModelChoiceIteratorValue`
 will break stuff?

 P.S. I'm reopening this issue so a PR that adds some clarification to the
 docs/release notes can target this issue.

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

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

Re: [Django] #32013: Field choice attribute returns different objects in forms. (was: TypeError: Field 'id' expected a number but got

2020-09-17 Thread Django

#32013: Field choice attribute returns different objects in forms.
---+--
 Reporter:  Jaap Roes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  3.1
 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/063.e0a8dbe4b9de3867f02386ed5ce365d6%40djangoproject.com.

Re: [Django] #32013: TypeError: Field 'id' expected a number but got

2020-09-17 Thread Django

#32013: TypeError: Field 'id' expected a number but got

---+--
 Reporter:  Jaap Roes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  3.1
 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
---+--
Changes (by felixxm):

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


Comment:

 Yes is a documented (see
 [https://docs.djangoproject.com/en/3.1/ref/forms/fields/#iterating-
 relationship-choices "Iterating relationship choices"] and
 
[https://docs.djangoproject.com/en/3.1/ref/forms/fields/#django.forms.ModelChoiceIterator.__iter__
 ModelChoiceIterator.__iter__()]) and intended change (see #30998), it also
 simplifies your code. I guess we could add a short note in the "Backwards
 incompatible" section. Would you like to prepare a clarification? If not I
 can add sth.

 > I'm not sure if this is fixable. Maybe it's possible to somehow proxy to
 the value attribute when evaluating a ModelChoiceIteratorValue in the the
 context of a database lookup?

 Yes, you can use `k.value`.

-- 
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/063.b61359a96334a5101f69018db88c2b1a%40djangoproject.com.

Re: [Django] #32013: TypeError: Field 'id' expected a number but got

2020-09-17 Thread Django

#32013: TypeError: Field 'id' expected a number but got

Comment (by Jaap Roes):

I guess this is technically documented here

https://docs.djangoproject.com/en/3.1/ref/forms/fields/#django.forms.ModelChoiceIteratorValue
and in the release notes (under the //Minor features// heading).

Replacing the `obj = SomeModel.objects.get(pk=k)` line with `obj =
k.instance` fixes the issue (and avoids a lookup).

However, it's not a very graceful way of discovering this new feature
(luckily we have pretty good coverage in our test suite).

I'm not sure if this is fixable. Maybe it's possible to somehow proxy to
the `value` attribute when evaluating a `ModelChoiceIteratorValue` in the
the context of a database lookup?

At the very least this should be listed under the //Backwards
incompatible// heading in the Django 3.1 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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.a444bd1b93cd208609dc86f91640d59c%40djangoproject.com.

[Django] #32013: TypeError: Field 'id' expected a number but got

2020-09-17 Thread Django

#32013: TypeError: Field 'id' expected a number but got

--+
   Reporter:  Jaap Roes   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  3.1
   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'm upgrading a project from Django 3.0 to Django 3.1. Running the tests
 shows 3 unexpected errors. All are the same `TypeError: Field 'id'
 expected a number but got `

 I can trace this back to this code in the `__init__` of a `ModelForm`.

 {{{
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 field = self.fields["some_fk_field"]

 new_choices = []
 for k, v in field.choices:
 do_add = True

 if not k:
 new_choices.append((k, v))
 continue

 obj = SomeModel.objects.get(pk=k)  # *CRASH*

 [...snip a bunch logic...]

 if do_add:
 new_choices.append((k, v))

 field.choices = new_choices
 }}}

 We've recently inherited this code, added tests and upgraded all the way
 from 1.4 to 3.0. This bit of code worked in all previous versions but has
 started raising errors in 3.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/048.41cddc1fb11380b8e74df4a2c2a09fe5%40djangoproject.com.

Re: [Django] #17664: {% if %} template tag silences exceptions inconsistently

2020-09-17 Thread Django

#17664: {% if %} template tag silences exceptions inconsistently
-+-
Reporter: Tai Lee |Owner: Robert
| Roskam
Type: Bug | Status: assigned
Component: Template system | Version: master
Severity: Normal | Resolution:
Keywords: smart if tag | Triage Stage: Accepted
queryset exception silenced|
Has patch: 1| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-

Comment (by felixxm):

I totally agree with
[https://code.djangoproject.com/ticket/17664#comment:27 Carlton]. This is
a huge change in the current longstanding behavior that would make the DTL
less user-friendly and would force users to rewrite templates in bulk with
no benefits. I also don't agree that the current behavior has important
security implications, even if it's used for permission checks then
showing sensitive data in `{% else %}` block seems like an unusual
pattern, moreover to expose sensitive data we need to also make a typo and
don't have any tests, that's an edge case, which should not force most of
users to rewrite their templates. In order to work with the DTL's
behavior, moving such logic up to the view or into a template tag are the
long established approaches.

I think we should decide which exceptions should be suppressed
([https://code.djangoproject.com/ticket/17664#comment:13 as suggested by
Colin]). `AttributeError`, `KeyError`, and `IndexError` sound like a good
starting point.

--
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.8ad57b04e40432c909ca57fca5b1fa57%40djangoproject.com.

Re: [Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}.

2020-09-17 Thread Django

#32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}.
-+-
 Reporter:  Jaap Roes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  testrunner crash | Triage Stage:  Accepted
  setup database migrations  |
  disabled   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jaap Roes):

 That seems similar to the solution I've been using for a while:

 {{{
 class NoMigrations:
 """Disable migrations for all apps"""

 def __getitem__(self, item):
 return None

 def __contains__(self, item):
 return True

 MIGRATION_MODULES = NoMigrations()
 }}}

 (Which I also suggested it as a temporary solution in the original ticket
 https://code.djangoproject.com/ticket/25388#comment:20)

 I hadn't actually tried this `MIGRATION_MODULES` override on this project
 before. I just did a test run with the override and or some reason I had
 to add a `fixtures = ['myapp/initial_data.json']` line to some of the
 `TestCase` classes that worked fine without it before. It seems that these
 test cases really needed this fixture, but for some reason worked fine
 when migrations are enabled. Is (test) fixture loading somehow tied to
 migrations?

 Anyway, the tests work fine (the same 3 failures) with the
 `MIGRATION_MODULES` override, so it seems like it would be a reasonable
 alternative solution.

-- 
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/063.df32381efc46e37816a1943e9cce6e1c%40djangoproject.com.

Re: [Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}.

2020-09-17 Thread Django

#32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}.
-+-
 Reporter:  Jaap Roes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  testrunner crash | Triage Stage:  Accepted
  setup database migrations  |
  disabled   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Mocking `settings.MIGRATION_MODULES` to `None` for all apps sounds like an
 easier fix, see draft below:
 {{{
 diff --git a/django/db/backends/base/creation.py
 b/django/db/backends/base/creation.py
 index 503f7f56fd..3c0338d359 100644
 --- a/django/db/backends/base/creation.py
 +++ b/django/db/backends/base/creation.py
 @@ -69,6 +69,22 @@ class BaseDatabaseCreation:
  database=self.connection.alias,
  run_syncdb=True,
  )
 +else:
 +try:
 +old = settings.MIGRATION_MODULES
 +settings.MIGRATION_MODULES = {
 +app.label: None
 +for app in apps.get_app_configs()
 +}
 +call_command(
 +'migrate',
 +verbosity=max(verbosity - 1, 0),
 +interactive=False,
 +database=self.connection.alias,
 +run_syncdb=True,
 +)
 +finally:
 +settings.MIGRATION_MODULES = old

  # We then serialize the current state of the database into a
 string
  # and store it on the connection. This slightly horrific process
 is so people
 }}}
 but I'm not convinced.

-- 
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/063.c394041b0145f4cc932e7e658bd88b64%40djangoproject.com.

Re: [Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}. (was: Test runner setup_databases crashes with "TEST": {"MIGRATE": False})

2020-09-17 Thread Django

#32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}.
-+-
 Reporter:  Jaap Roes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  testrunner crash | Triage Stage:  Accepted
  setup database migrations  |
  disabled   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: Jon Dufresne (added)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this report, now I see that we need to synchronize all apps
 when `MIGRATE` is `False`, see
 [https://code.djangoproject.com/ticket/25388#comment:19 comment]. I've
 totally missed this when reviewing
 f5ebdfce5c417f9844e86bccc2f12577064d4bad. We can remove the feature from
 3.1 if fix is not trivial.

-- 
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/063.6a4b1c4c71b6447532e162f038f9a98f%40djangoproject.com.

Re: [Django] #32010: Unexpected behaviour of MultiValueDict.getlist in conjunction with map

2020-09-17 Thread Django

#32010: Unexpected behaviour of MultiValueDict.getlist in conjunction with map
-+--
 Reporter:  Etienne Ott  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  3.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
-+--

Comment (by Etienne Ott):

 It seems that when creating the example above I didn't reproduce any kind
 of bug and instead constructed an incorrect use of `MultiValueDict`.
 Further digging has revealed that using the membership operator `in` on
 generators like `map` is also incorrect usage. The pythonic way is to
 check a list made by list comprehension, e.g. `if number in [x for x in
 map(int, somelist)]`. My apologies for wasting time with something
 unrelated to Django.

-- 
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.fce105f4e63c4094a1118c0948b4cb54%40djangoproject.com.

[Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}

2020-09-17 Thread Django

#32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}
-+-
   Reporter:  Jaap Roes  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing|Version:  3.1
  framework  |   Keywords:  testrunner crash
   Severity:  Normal |  setup database migrations disabled
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm trying to upgrade a project from Django 3.0 to Django 3.1 and wanted
 to try out the new `"TEST": {"MIGRATE": False}` database setting.

 Sadly I'm running into an issue immediately when running `./manage.py
 test`.

 Removing the `"TEST": {"MIGRATE": False}` line allows the tests to run. So
 this is not blocking the upgrade for us, but it would be nice if we were
 able to use the new feature to skip migrations during testing.

 For reference, this project was recently upgraded from Django 1.4 all the
 way to 3.0 so there might be some legacy cruft somewhere that triggers
 this.

 Here's the trackeback. I'll try to debug this some more.

 {{{
 Traceback (most recent call last):
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedTable: relation "django_admin_log" does not exist
 LINE 1: ...n_flag", "django_admin_log"."change_message" FROM "django_ad...
  ^
 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.6/site-
 packages/django/db/models/sql/compiler.py", line 1156, in execute_sql
 cursor.execute(sql, params)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 66, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/usr/local/lib/python3.6/site-packages/django/db/utils.py", line
 90, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: relation "django_admin_log" does not
 exist
 LINE 1: ...n_flag", "django_admin_log"."change_message" FROM "django_ad...
  ^
 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "./manage.py", line 15, in 
 main()
   File "./manage.py", line 11, in main
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 401, in
 execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 395, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python3.6/site-
 packages/django/core/management/commands/test.py", line 23, in
 run_from_argv
 super().run_from_argv(argv)
   File "/usr/local/lib/python3.6/site-
 packages/django/core/management/base.py", line 330, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/usr/local/lib/python3.6/site-
 packages/django/core/management/base.py", line 371, in execute
 output = self.handle(*args, **options)
   File "/usr/local/lib/python3.6/site-
 packages/django/core/management/commands/test.py", line 53, in handle
 failures = test_runner.run_tests(test_labels)
   File "/usr/local/lib/python3.6/site-packages/django/test/runner.py",
 line 695, in run_tests
 old_config = self.setup_databases(aliases=databases)
   File "/usr/local/lib/python3.6/site-packages/django/test/runner.py",
 line 616, in setup_databases
 self.parallel, **kwargs
   File "/usr/local/lib/python3.6/site-packages/django/test/utils.py", line
 174, in setup_databases
 serialize=connection.settings_dict['TEST'].get('SERIALIZE', True),
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/base/creation.py", line 78, in create_test_db
 self.connection._test_serialized_contents =
 self.serialize_db_to_string()
   File "/usr/local/lib/python3.6/site-

Re: [Django] #28805: Add database functions for regular expressions, e.g. RegexpReplace

2020-09-17 Thread Django

#28805: Add database functions for regular expressions, e.g. RegexpReplace
-+-
 Reporter:  Joey Wilhelm |Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 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/069.e17ea79746cd91a1f1fad61428019320%40djangoproject.com.

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

2020-09-17 Thread Django

#31880: QuerySet.aggregate() mixes annotated fields names.
-+-
 Reporter:  Thodoris |Owner:  David
  Sotiropoulos   |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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 felixxm):

 * has_patch:  1 => 0


Comment:

 To sum up, I think supporting this edge case isn't worth adding extra
 complexity, we should raise an error. You can always use different
 aliases.

-- 
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/066.453c16a57621bb31940e77e8ea71d6dd%40djangoproject.com.

Re: [Django] #32010: Unexpected behaviour of MultiValueDict.getlist in conjunction with map

2020-09-17 Thread Django

#32010: Unexpected behaviour of MultiValueDict.getlist in conjunction with map
-+--
 Reporter:  Etienne Ott  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  3.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
-+--
Changes (by Carlton Gibson):

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


Comment:

 > mvdict = MultiValueDict({"number": "54321"})

 This is incorrect usage. If instantiated manually (which is not part of
 the documented public API) the value of each item should be a list.

 Compare:


 {{{
 >>> mvdict = MultiValueDict({"number": "54321"})
 >>> mvdict.getlist("number")
 ['5', '4', '3', '2', '1']
 >>> mvdict = MultiValueDict({"number": ["54321"]})
 >>> mvdict.getlist("number")
 ['54321']
 }}}

 Note that the public `QueryDict` handles this as required:

 {{{
 >>> from django.http import QueryDict
 >>> q = QueryDict("number=54321")
 >>> q.getlist("number")
 ['54321']
 }}}

-- 
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.121b880668ec7bcd94f10a66dcb0af7f%40djangoproject.com.

Re: [Django] #31916: Combined queryset crash on combined querysets with ordering.

2020-09-17 Thread Django

#31916: Combined queryset crash on combined querysets with ordering.
-+-
 Reporter:  StefanosChaliasos|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 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 GitHub ):

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


Comment:

 In [changeset:"a046bcadbee2dc0e6c889f82c08b5a21a32359ad" a046bca]:
 {{{
 #!CommitTicketReference repository=""
 revision="a046bcadbee2dc0e6c889f82c08b5a21a32359ad"
 Fixed #31916 -- Fixed combined queryset crash when combining with ordered
 combined querysets.
 }}}

-- 
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.585ae7c6c3439d907c49f199112fff19%40djangoproject.com.

Re: [Django] #32015: psycopg2 jsonb is not loaded with connections.cursor (was: BUG: psycopg2 json is not loaded with connections.cursor)

Re: [Django] #32016: mail_admins handler cannot be configured. (was: ValueError: Unable to configure handler 'mail_admins' on custom logging configuration)

Re: [Django] #32005: Allow disabling of auto-404-redirection in LocaleMiddleware

[Django] #32016: ValueError: Unable to configure handler 'mail_admins' on custom logging configuration

[Django] #32015: BUG: psycopg2 json is not loaded with connections.cursor

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

Re: [Django] #20516: Allow use of prepared statements

Re: [Django] #32013: Field choice attribute returns different objects in forms.

Re: [Django] #28939: Document which ORM methods provide an instance hint to database routers

Re: [Django] #28939: Document which ORM methods provide an instance hint to database routers

Re: [Django] #32013: Field choice attribute returns different objects in forms.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

Re: [Django] #32014: When Upgrading Django1.11 to Django latest

Re: [Django] #32013: Field choice attribute returns different objects in forms.

[Django] #32014: When Upgrading Django1.11 to Django latest

Re: [Django] #32013: Field choice attribute returns different objects in forms.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

Re: [Django] #32013: Field choice attribute returns different objects in forms.

Re: [Django] #32013: Field choice attribute returns different objects in forms. (was: TypeError: Field 'id' expected a number but got

Re: [Django] #32013: TypeError: Field 'id' expected a number but got

Re: [Django] #32013: TypeError: Field 'id' expected a number but got

[Django] #32013: TypeError: Field 'id' expected a number but got

Re: [Django] #17664: {% if %} template tag silences exceptions inconsistently

Re: [Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}.

Re: [Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}.

Re: [Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}. (was: Test runner setup_databases crashes with "TEST": {"MIGRATE": False})

Re: [Django] #32010: Unexpected behaviour of MultiValueDict.getlist in conjunction with map

[Django] #32012: Test runner setup_databases crashes with "TEST": {"MIGRATE": False}

Re: [Django] #28805: Add database functions for regular expressions, e.g. RegexpReplace

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

Re: [Django] #32010: Unexpected behaviour of MultiValueDict.getlist in conjunction with map

Re: [Django] #31916: Combined queryset crash on combined querysets with ordering.

33 matches

Site Navigation

Mail list logo

Footer information