Re: [Django] #35271: Old migrations with UniqueConstraint fail when using psycopg3

[Django]

#35271: Old migrations with UniqueConstraint fail when using psycopg3
+--
 Reporter:  Adam Zahradník  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  5.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 David Sanders):

 Please paste the _actual_ model field & generated migration for that field
 so we can determine _exactly_ what is happening.

 I'm using Django 4.0.6 and the model

 {{{
 class Foo(models.Model):
 name = models.CharField(max_length=255)
 label = models.CharField(max_length=255)

 class Meta:
 constraints = [
 models.UniqueConstraint(
 "name",
 "label",
 name="unique_pair",
 ),
 ]
 }}}

 generates the migration

 {{{
 migrations.AddConstraint(
 model_name='foo',
 constraint=models.UniqueConstraint(django.db.models.expressions.F('name'),
 django.db.models.expressions.F('label'), name='unique_pair'),
 ),
 }}}
-- 
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/0107018e0d9a2b5a-18d267b3-ae09-493e-8cba-863bc75eca64-00%40eu-central-1.amazonses.com.

Re: [Django] #35271: Old migrations with UniqueConstraint fail when using psycopg3

[Django]

#35271: Old migrations with UniqueConstraint fail when using psycopg3
+--
 Reporter:  Adam Zahradník  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  5.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 Adam Zahradník):

 When looking at our UniqueConstraint in the model, we never used
 `UniqueConstraint(["field"],...)`, but either
 `UniqueConstraint(fields=[..])` or `UniqueConstraint("field",...)`. Both
 of which are documented in the docs:
 https://docs.djangoproject.com/en/5.0/ref/models/constraints/#uniqueconstraint

 I see how `UniqueConstraint([...])` would create a wrong constraint, as
 the array would be accepted as an expression, but I don't think that is
 the problem here.

 We already used this model in production for quite some time, and it is
 definitely possible to insert values into the table.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e0d8fbdbd-f38d9223-71b5-483d-8d76-742bb7d47987-00%40eu-central-1.amazonses.com.

Re: [Django] #35269: GeneratedFields can't be defined on RelatedFields

[Django]

#35269: GeneratedFields can't be defined on RelatedFields
-+-
 Reporter:  Perrine L.   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Comment:

 Related fields were never intended to be used as `output_field`s.
 Moreover, as far as I'm aware, `GeneratedField`s cannot refer fields from
 external models, so I'm not exactly sure what kind of column you want to
 add. Please add a sample project that reproduces your issue, and provide a
 valid column DDL definition that you believe is not currently 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/0107018e0ce8ab6a-ff9a6c62-ac22-46d8-a6e3-39c59663446c-00%40eu-central-1.amazonses.com.

Re: [Django] #35267: Correct TIME_ZONE setting reference in time zone topic. (was: DateTimeField does not seem to be translated back to the local timezone on data retrieval on Postgres)

[Django]

#35267: Correct TIME_ZONE setting reference in time zone topic.
-+-
 Reporter:  Josh Smeaton |Owner:  Josh
 Type:   |  Smeaton
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  orm datetimefield| Triage Stage:  Accepted
  timezones  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * component:  Database layer (models, ORM) => Documentation
 * easy:  0 => 1
 * owner:  nobody => Josh Smeaton
 * stage:  Unreviewed => Accepted
 * status:  new => assigned
 * summary:
 DateTimeField does not seem to be translated back to the local
 timezone on data retrieval on Postgres
 => Correct TIME_ZONE setting reference in time zone topic.
 * type:  Uncategorized => Cleanup/optimization

Comment:

 Replying to [comment:4 Josh Smeaton]:
 > The database connection settings have their own TIME_ZONE setting:
 https://docs.djangoproject.com/en/5.0/ref/settings/#time-zone, which is
 what the previous docs I was referring to must have been referencing:
 https://docs.djangoproject.com/en/4.2/topics/i18n/timezones/#postgresql
 >
 > It makes sense to me now.

 Thanks Josh.  Assigned to you, I hope you don't mind fixing it ;)
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e0cd819e9-3f5e16b4-9e6c-4eeb-a668-fc65400648aa-00%40eu-central-1.amazonses.com.

Re: [Django] #14831: Django Template Style Guide

[Django]

#14831: Django Template Style Guide
-+-
 Reporter:  Simon Meers  |Owner:  Ryan
 |  Cheley
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  template, style, | Triage Stage:  Accepted
  format |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan Cheley):

 * 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/0107018e0c989a78-63bf6a75-ea3a-422c-8236-3370d5ba80a1-00%40eu-central-1.amazonses.com.

Re: [Django] #14831: Django Template Style Guide

[Django]

#14831: Django Template Style Guide
-+-
 Reporter:  Simon Meers  |Owner:  Ryan
 |  Cheley
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  template, style, | Triage Stage:  Accepted
  format |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan Cheley):

 * has_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/0107018e0c92b85f-7a8bbfe1-cd33-4686-ab83-44f10b831e94-00%40eu-central-1.amazonses.com.

Re: [Django] #35271: Old migrations with UniqueConstraint fail when using psycopg3

[Django]

#35271: Old migrations with UniqueConstraint fail when using psycopg3
+--
 Reporter:  Adam Zahradník  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  5.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 David Sanders):

 * resolution:   => invalid
 * stage:  Accepted => Unreviewed
 * status:  new => closed

Comment:

 Actually, on second thoughts:

 The problem here is the misunderstanding of using
 `UniqueConstraint(['field_1', 'field_2'])` - on psycopg2 this is
 interpreted as the literal `ARRAY['field_1'::text, 'field_2'::text']`.
 Which will fail for **any** value inserted into the table.

 Given this, I think this should be categorised as "Invalid" 
-- 
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/0107018e0c5ffd30-e080619f-fc87-475d-86b1-3cbdbfe0891a-00%40eu-central-1.amazonses.com.

Re: [Django] #35271: Old migrations with UniqueConstraint fail when using psycopg3

[Django]

#35271: Old migrations with UniqueConstraint fail when using psycopg3
+
 Reporter:  Adam Zahradník  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by David Sanders):

 * stage:  Unreviewed => Accepted

Comment:

 Thanks for the report 

 Looks like it's not just old migrations but a model with the following
 will produce the same migration & error with psycopg (3)

 {{{
 class Foo(models.Model):
 name = models.CharField()
 label = models.CharField()

 class Meta:
 constraints = [
 models.UniqueConstraint(
 ["name", "label"],
 name="unique_pair",
 ),
 ]
 }}}

 Migration generated:

 {{{
 class Migration(migrations.Migration):
 initial = True

 dependencies = []

 operations = [
 migrations.CreateModel(
 name="Foo",
 fields=[
 (
 "id",
 models.BigAutoField(
 auto_created=True,
 primary_key=True,
 serialize=False,
 verbose_name="ID",
 ),
 ),
 ("name", models.CharField()),
 ("label", models.CharField()),
 ],
 options={
 "constraints": [
 models.UniqueConstraint(["name", "label"],
 name="unique_pair")
 ],
 },
 ),
 ]
 }}}
-- 
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/0107018e0c4a4dc0-97580e6d-1438-40b1-b437-d65af48faa6c-00%40eu-central-1.amazonses.com.

Re: [Django] #35270: Optimize Model._meta._property_names

[Django]

#35270: Optimize Model._meta._property_names
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Natalia Bidart):

 I'm not so sure about this one, particularly after having read the history
 in the relevant PRs ([https://github.com/django/django/pull/7598 the
 original optimization in this code] and
 [https://github.com/django/django/pull/8599 its regression fix]).

 I wonder, would using [https://github.com/django/django/pull/8601 the
 solution proposed for "1.11.x"] be an option for getting rid of
 `inspect.getattr_static`? I'm not a fan of the custom weak key cache, it
 feels like an unnecessary adding to the framework only for optimization
 purposes.
-- 
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/0107018e0c37ef48-94257e51-eb4e-473b-83f3-32323a6c69e7-00%40eu-central-1.amazonses.com.

Re: [Django] #35267: DateTimeField does not seem to be translated back to the local timezone on data retrieval on Postgres

[Django]

#35267: DateTimeField does not seem to be translated back to the local timezone 
on
data retrieval on Postgres
-+-
 Reporter:  Josh Smeaton |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm datetimefield| Triage Stage:
  timezones  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Natalia Bidart):

 Replying to [comment:4 Josh Smeaton]:
 > The database connection settings have their own TIME_ZONE setting:
 https://docs.djangoproject.com/en/5.0/ref/settings/#time-zone, which is
 what the previous docs I was referring to must have been referencing:
 https://docs.djangoproject.com/en/4.2/topics/i18n/timezones/#postgresql
 >
 > It makes sense to me now.

 Amazing, thank you for letting us know. Do you think the first docs you
 read still need adjustment? I'm thinking that the `TIME_ZONE` setting link
 in the paragraph would be better pointed to this instead:
 https://docs.djangoproject.com/en/dev/ref/settings/#time-zone
-- 
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/0107018e0c276cb4-68fe7528-7ed0-42ba-addd-682744eb1e48-00%40eu-central-1.amazonses.com.

Re: [Django] #35267: DateTimeField does not seem to be translated back to the local timezone on data retrieval on Postgres

[Django]

#35267: DateTimeField does not seem to be translated back to the local timezone 
on
data retrieval on Postgres
-+-
 Reporter:  Josh Smeaton |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm datetimefield| Triage Stage:
  timezones  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Josh Smeaton):

 The database connection settings have their own TIME_ZONE setting:
 https://docs.djangoproject.com/en/5.0/ref/settings/#time-zone, which is
 what the previous docs I was referring to must have been referencing:
 https://docs.djangoproject.com/en/4.2/topics/i18n/timezones/#postgresql

 It makes sense to me now.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e0b7f0404-d1a43e06-31d8-4bbc-aeac-24688afb79ce-00%40eu-central-1.amazonses.com.

Re: [Django] #35271: Old migrations with UniqueConstraint fail when using psycopg3

[Django]

#35271: Old migrations with UniqueConstraint fail when using psycopg3
+--
 Reporter:  Adam Zahradník  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Adam Zahradník):

 * type:  Uncategorized => Bug

-- 
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/0107018e0b520e84-3db339e4-5d03-447d-aded-50e3ded01a81-00%40eu-central-1.amazonses.com.

[Django] #35271: Old migrations with UniqueConstraint fail when using psycopg3

[Django]

#35271: Old migrations with UniqueConstraint fail when using psycopg3
--+
   Reporter:  Adam Zahradník  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Migrations  |Version:  5.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 We have noticed that migrations generated with Django 4.0.6 containing
 UniqueConstraint fail to apply under Django 5.0.3 when using psycopg3.

 The problematic operation:
 {{{
 migrations.AddConstraint(
 model_name="model",
 constraint=models.UniqueConstraint(
["some", "fields", "here"],
name="constraint_name",
 ),
 ),
 }}}

 Which fails with the following error:
 {{{
 psycopg.errors.UndefinedObject: data type unknown has no default operator
 class for access method "btree"
 HINT:  You must specify an operator class for the index or define a
 default operator class for the data type.
 }}}

 However, when using psycopg2, the migration gets applied without any
 problem.

 We also noticed that a migration generated by Django 4.1.5 produces the
 following operation, which runs successfully on both psycopg versions:
 {{{
 migrations.AddConstraint(
 model_name="model",
 constraint=models.UniqueConstraint(
 models.F("some"),
 models.F("fields"),
 models.F("here"),
 name="constraint_name",
 ),
 ),
 }}}

 A current way to fix failing migrations is to pass the list of fields to a
 keyword argument `fields`:
 {{{
 migrations.AddConstraint(
 model_name="model",
 constraint=models.UniqueConstraint(
fields=["some", "fields", "here"],
name="constraint_name",
 ),
 ),
 }}}
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e0b4ea0a8-07997abd-9e04-48f3-ba3c-279e8a3bdbca-00%40eu-central-1.amazonses.com.

Re: [Django] #35266: Optimize RelatedField._check_clashes()

[Django]

#35266: Optimize RelatedField._check_clashes()
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  dev
  checks)|
 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 ):

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

Comment:

 In [changeset:"ab22b7c65fa3dc60b097362939ccf49c1c47bc56" ab22b7c]:
 {{{#!CommitTicketReference repository=""
 revision="ab22b7c65fa3dc60b097362939ccf49c1c47bc56"
 Fixed #35266 -- Deferred formatting in RelatedField._check_clashes().
 }}}
-- 
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/0107018e0aee89e2-7dd0b3bb-3905-4856-9a12-e6d970874e89-00%40eu-central-1.amazonses.com.

Re: [Django] #35252: Optimize django.urls.resolvers._route_to_regex()

[Django]

#35252: Optimize django.urls.resolvers._route_to_regex()
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  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 Natalia Bidart):

 * stage:  Unreviewed => Accepted

Comment:

 Accepting on the basis of the provided benchmarks and the initial feedback
 in the PR. Will also review the PR soon, thanks!
-- 
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/0107018e0ad84e59-4ec456fa-8b46-4f77-8e42-be8af4249892-00%40eu-central-1.amazonses.com.

Re: [Django] #35270: Optimize Model._meta._property_names

[Django]

#35270: Optimize Model._meta._property_names
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Adam Johnson:

Old description:

> Optimize Model._meta._property_names
>
> Continuing my project to optimize the system checks, I found some
> optimizations for `Options._meta._property_names`, which I found to take
> ~4% of the total runtime for checks.
>
> Most of this function’s runtime was being spent running
> `inspect.getattr_static()`. This is not surprising as it
> [https://github.com/python/cpython/blob/9b9e819b5116302cb4e471763feb2764eb17dde8/Lib/inspect.py#L1852
> jumps through many hoops] in order to avoid triggering attribute access.
>
> I added use of `getattr_static()` back in #28269 /
> ed244199c72f5bbf33ab4547e06e69873d7271d0 to fix a bug with instance
> descriptors. But I think it’s overly cautious, and we can assume that
> accessing the `__dict__` of the model class will work fine.
>
> Two optimizations make the function run in negligible time:
>
> 1. Changing the function to use  `__dict__` directly
> 2. Caching on a per-class basis. This requires using a weak-reference to
> classes, as we shouldn’t mutate base classes in the MRO, some of which
> can be non-model subclasses, like `Model` itself for the `pk` property,
> `object`, or any mixins.
>
> Before optimization stats:
>
> 106 calls to `_property_names` took 26ms, or ~4% of the total runtime of
> system checks.
>
> After optimization:
>
> The same calls take 1ms, or ~0.2% of the total runtime. (The real runtime
> may be <1ms, but shows as 1 due to rounding up by cProfile.)

New description:

 Continuing my project to optimize the system checks, I found some
 optimizations for `Options._meta._property_names`, which I found to take
 ~4% of the total runtime for checks.

 Most of this function’s runtime was being spent running
 `inspect.getattr_static()`. This is not surprising as it
 
[https://github.com/python/cpython/blob/9b9e819b5116302cb4e471763feb2764eb17dde8/Lib/inspect.py#L1852
 jumps through many hoops] in order to avoid triggering attribute access.

 I added use of `getattr_static()` back in #28269 /
 ed244199c72f5bbf33ab4547e06e69873d7271d0 to fix a bug with instance
 descriptors. But I think it’s overly cautious, and we can assume that
 accessing the `__dict__` of the model class will work fine.

 Two optimizations make the function run in negligible time:

 1. Changing the function to use  `__dict__` directly
 2. Caching on a per-class basis. This requires using a weak-reference to
 classes, as we shouldn’t mutate base classes in the MRO, some of which can
 be non-model subclasses, like `Model` itself for the `pk` property,
 `object`, or any mixins.

 Before optimization stats:

 106 calls to `_property_names` took 26ms, or ~4% of the total runtime of
 system checks.

 After optimization:

 The same calls take 1ms, or ~0.2% of the total runtime. (The real runtime
 may be <1ms, but shows as 1 due to rounding up by cProfile.)

--
-- 
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/0107018e0abd41aa-c526e3e0-e913-4303-ab80-956d41476c87-00%40eu-central-1.amazonses.com.

[Django] #35270: Optimize Model._meta._property_names

[Django]

#35270: Optimize Model._meta._property_names
-+-
   Reporter:  Adam   |  Owner:  Adam Johnson
  Johnson|
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Optimize Model._meta._property_names

 Continuing my project to optimize the system checks, I found some
 optimizations for `Options._meta._property_names`, which I found to take
 ~4% of the total runtime for checks.

 Most of this function’s runtime was being spent running
 `inspect.getattr_static()`. This is not surprising as it
 
[https://github.com/python/cpython/blob/9b9e819b5116302cb4e471763feb2764eb17dde8/Lib/inspect.py#L1852
 jumps through many hoops] in order to avoid triggering attribute access.

 I added use of `getattr_static()` back in #28269 /
 ed244199c72f5bbf33ab4547e06e69873d7271d0 to fix a bug with instance
 descriptors. But I think it’s overly cautious, and we can assume that
 accessing the `__dict__` of the model class will work fine.

 Two optimizations make the function run in negligible time:

 1. Changing the function to use  `__dict__` directly
 2. Caching on a per-class basis. This requires using a weak-reference to
 classes, as we shouldn’t mutate base classes in the MRO, some of which can
 be non-model subclasses, like `Model` itself for the `pk` property,
 `object`, or any mixins.

 Before optimization stats:

 106 calls to `_property_names` took 26ms, or ~4% of the total runtime of
 system checks.

 After optimization:

 The same calls take 1ms, or ~0.2% of the total runtime. (The real runtime
 may be <1ms, but shows as 1 due to rounding up by cProfile.)
-- 
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/0107018e0ab8c691-30bfc26c-08fa-4abc-91c3-a67d031fbc94-00%40eu-central-1.amazonses.com.

Re: [Django] #35261: Media Path as Objects - Documentation fix and usage example

[Django]

#35261: Media Path as Objects - Documentation fix and usage example
-+-
 Reporter:  Leandro de Souza |Owner:  Leandro
 |  de Souza
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Documentation,   | Triage Stage:  Ready for
  Media  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak ):

 In [changeset:"17855bf578da756b1804542133dd1e514c15a1f3" 17855bf]:
 {{{#!CommitTicketReference repository=""
 revision="17855bf578da756b1804542133dd1e514c15a1f3"
 [5.0.x] Fixed #35261 -- Corrected Media JS example of object-based paths
 in docs.

 `rel` attribute is not valid on `` tags.
 Backport of 368a8a3a83885a13776a530920f0317a40e7989d from main
 }}}
-- 
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/0107018e0aa0252d-122ae53c-c1b4-4678-98be-b66483963259-00%40eu-central-1.amazonses.com.

Re: [Django] #35261: Media Path as Objects - Documentation fix and usage example

[Django]

#35261: Media Path as Objects - Documentation fix and usage example
-+-
 Reporter:  Leandro de Souza |Owner:  Leandro
 |  de Souza
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Documentation,   | Triage Stage:  Ready for
  Media  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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

Comment:

 In [changeset:"368a8a3a83885a13776a530920f0317a40e7989d" 368a8a3]:
 {{{#!CommitTicketReference repository=""
 revision="368a8a3a83885a13776a530920f0317a40e7989d"
 Fixed #35261 -- Corrected Media JS example of object-based paths in docs.

 `rel` attribute is not valid on `` tags.
 }}}
-- 
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/0107018e0a9f4792-26c32c6f-1640-4ffe-b8c5-578369ad5ea1-00%40eu-central-1.amazonses.com.

Re: [Django] #35266: Optimize RelatedField._check_clashes()

[Django]

#35266: Optimize RelatedField._check_clashes()
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 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):

 * 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/0107018e0a9e01eb-3e0d382f-82bb-4f47-aba0-bc6f0d5c7c5c-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  Damir
 Type:   |  Nafikov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (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 bcail):

 * cc: bcail (added)

Comment:

 @Damir Nafikov, are you still working on this ticket?
-- 
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/0107018e0a61050c-9078e13a-b335-44d4-9e67-3876dfa5ddfb-00%40eu-central-1.amazonses.com.

Re: [Django] #23337: CircularDependencyError when squashing migrations

[Django]

#23337: CircularDependencyError when squashing migrations
---+
 Reporter:  Richard Eames  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  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
---+
Comment (by bcail):

 It looks like the first `squashmigrations` command for the cheese app
 results in a circular dependency, so a `migrate` or `makemigrations`
 command fails with the CircularDependencyError (even without squashing
 migrations in the eggs app).

 Would it be helpful to add a check in the `squashmigrations` command to
 look at its output and throw an error instead of writing out a squashed
 migration that causes a CircularDependencyError?
-- 
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/0107018e0a426ccd-0c8f1c08-cf00-4a8d-b48c-524016de2336-00%40eu-central-1.amazonses.com.

[Django] #35269: GeneratedFields can't be defined on RelatedFields

[Django]

#35269: GeneratedFields can't be defined on RelatedFields
-+-
   Reporter:  Perrine|  Owner:  nobody
  L. |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  5.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  |
-+-
 It is not possible to define a GeneratedField with a ForeignKey or a
 ManyToManyField as an output_field.
 When those RelatedFields are defined as output_field, an error is raised

 ```AttributeError: 'ForeignKey' object has no attribute 'opts'``` line
 190, in _check_relation_model_exists or line 494, in related_query_name
 (cf.
 
https://github.com/django/django/blob/3d4fe39bac082b835a2d82b717b6ae88ea70ea15/django/db/models/fields/related.py)

 At least with Postgres as a backend, there doesn't seem to be any
 technical impossibility to make a GeneratedField on a ForeignKey or
 ManyToMany fields : https://www.postgresql.org/docs/current/ddl-generated-
 columns.html
-- 
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/0107018e0a3edac9-5a386102-cf20-4f23-a0bc-7fc254fd4515-00%40eu-central-1.amazonses.com.

Re: [Django] #35261: Media Path as Objects - Documentation fix and usage example

[Django]

#35261: Media Path as Objects - Documentation fix and usage example
-+-
 Reporter:  Leandro de Souza |Owner:  Leandro
 |  de Souza
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  Documentation,   | Triage Stage:  Ready for
  Media  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e097f8242-27036cd0-49ca-4f50-bb31-cb877fbaf733-00%40eu-central-1.amazonses.com.

Re: [Django] #35267: DateTimeField does not seem to be translated back to the local timezone on data retrieval on Postgres

[Django]

#35267: DateTimeField does not seem to be translated back to the local timezone 
on
data retrieval on Postgres
-+-
 Reporter:  Josh Smeaton |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm datetimefield| Triage Stage:
  timezones  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Aymeric Augustin (added)

Comment:

 Replying to [comment:2 Josh Smeaton]:
 > Thank you!
 >
 > I think the docs are ambiguous. It sounds like the configured time zone
 will be used for the connection from the docs I linked, but in practice
 the connection uses UTC unless a query is executed on the session? Or is
 there another connection parameter that controls the session timezone?
 >
 > Might be worth a docs update to clarify the current behaviour?

 Doc clarifications are always welcome. I hope that Aymeric will chime in
 ;)
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e097bf056-287cd82c-f522-4c32-99fc-6d18e55a47cf-00%40eu-central-1.amazonses.com.

Re: [Django] #35267: DateTimeField does not seem to be translated back to the local timezone on data retrieval on Postgres

[Django]

#35267: DateTimeField does not seem to be translated back to the local timezone 
on
data retrieval on Postgres
-+-
 Reporter:  Josh Smeaton |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm datetimefield| Triage Stage:
  timezones  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Josh Smeaton):

 Thank you!

 I think the docs are ambiguous. It sounds like the configured time zone
 will be used for the connection from the docs I linked, but in practice
 the connection uses UTC unless a query is executed on the session? Or is
 there another connection parameter that controls the session timezone?

 Might be worth a docs update to clarify the current behaviour?
-- 
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/0107018e09678c3c-e9f99f20-cf01-416e-a913-fc6bc3cf896f-00%40eu-central-1.amazonses.com.

Re: [Django] #21286: Fix commented out tests in serializers.test_data

[Django]

#21286: Fix commented out tests in serializers.test_data
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  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):

 * has_patch:  1 => 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/0107018e0958501b-36efa444-51af-4f23-9e05-8d2e1cdeafab-00%40eu-central-1.amazonses.com.

Re: [Django] #21286: Fix commented out tests in serializers.test_data

[Django]

#21286: Fix commented out tests in serializers.test_data
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  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
--+
Comment (by Mariusz Felisiak ):

 In [changeset:"3d4fe39bac082b835a2d82b717b6ae88ea70ea15" 3d4fe39b]:
 {{{#!CommitTicketReference repository=""
 revision="3d4fe39bac082b835a2d82b717b6ae88ea70ea15"
 Refs #21286 -- Removed invalid commented out models and tests from
 serializer tests.

 FileField/ImageField cannot be primary keys, so serialization support
 for this case will not be implemented.

 XMLField was removed in d1290b5b43485c7018ba92981d34c1f96614924e.
 }}}
-- 
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/0107018e0957cb74-eb7f9cb4-0493-4e3f-8fd2-37c19735b576-00%40eu-central-1.amazonses.com.

Re: [Django] #35268: Migrations raise UnicodeDecodeError on PostgreSQL. (was: Error in Django Migration in PostgreSQL : UnicodeDecodeError during 'python manage.py migrate')

[Django]

#35268: Migrations raise UnicodeDecodeError on PostgreSQL.
-+-
 Reporter:  Azim1900 |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  PostgreSQL   | 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):

 * component:  Uncategorized => Database layer (models, ORM)
 * resolution:   => needsinfo
 * status:  new => closed
 * summary:
 Error in Django Migration in PostgreSQL  : UnicodeDecodeError during
 'python manage.py migrate'
 => Migrations raise UnicodeDecodeError on PostgreSQL.


Old description:

> When running the command 'python manage.py migrate' in a Django project,
> a UnicodeDecodeError occurs during the migration process.
>
>  The error trace indicates that the issue is related to decoding a byte
> (0xbb) at position 79, and the problematic code is within the PostgreSQL
> database backend connection setup. The error originates from the
> 'psycopg2' library, and the specific context points to a Unicode decoding
> problem in the 'data_handler.py' file. The error disrupts the migration
> process and prevents the successful execution of the command.
>
> Here is also Database Setting in  my  Django Project :
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'NAME': 'Databank',
> 'USER': 'user',
> 'PASSWORD': '123456',
> 'HOST': 'localhost',
> 'PORT': '5432',
> 'OPTIONS': {
> 'client_encoding': 'UTF8',
> }
> }
> }

New description:

 When running the command 'python manage.py migrate' in a Django project, a
 UnicodeDecodeError occurs during the migration process.

 The error trace indicates that the issue is related to decoding a byte
 (0xbb) at position 79, and the problematic code is within the PostgreSQL
 database backend connection setup. The error originates from the
 'psycopg2' library, and the specific context points to a Unicode decoding
 problem in the 'data_handler.py' file. The error disrupts the migration
 process and prevents the successful execution of the command.

 Here is also Database Setting in  my  Django Project :
 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'Databank',
 'USER': 'user',
 'PASSWORD': '123456',
 'HOST': 'localhost',
 'PORT': '5432',
 'OPTIONS': {
 'client_encoding': 'UTF8',
 }
 }
 }
 }}}

--
Comment:

 Hi, I don't think you've explained the issue in enough detail to confirm a
 bug in Django. Please reopen the ticket if you can debug your issue and
 provide details about why and where Django is at fault (or a sample
 project that reproduced the issue). If you're having trouble understanding
 how Django works, see TicketClosingReasons/UseSupportChannels for ways to
 get 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/0107018e0922a434-f3044897-9c78-4a46-9dec-22f702d6f793-00%40eu-central-1.amazonses.com.

Re: [Django] #35268: Error in Django Migration in PostgreSQL : UnicodeDecodeError during 'python manage.py migrate'

[Django]

#35268: Error in Django Migration in PostgreSQL  : UnicodeDecodeError during
'python manage.py migrate'
---+--
 Reporter:  Azim1900   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  5.0
 Severity:  Normal |   Resolution:
 Keywords:  PostgreSQL | 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 Azim1900:

Old description:

> When running the command 'python manage.py migrate' in a Django project,
> a UnicodeDecodeError occurs during the migration process.
>
>  The error trace indicates that the issue is related to decoding a byte
> (0xbb) at position 79, and the problematic code is within the PostgreSQL
> database backend connection setup. The error originates from the
> 'psycopg2' library, and the specific context points to a Unicode decoding
> problem in the 'vectordb_handler.py' file. The error disrupts the
> migration process and prevents the successful execution of the command.
>
> Here is also Database Setting in  my  Django Project :
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'NAME': 'Databank',
> 'USER': 'user',
> 'PASSWORD': '123456',
> 'HOST': 'localhost',
> 'PORT': '5432',
> 'OPTIONS': {
> 'client_encoding': 'UTF8',
> }
> }
> }

New description:

 When running the command 'python manage.py migrate' in a Django project, a
 UnicodeDecodeError occurs during the migration process.

  The error trace indicates that the issue is related to decoding a byte
 (0xbb) at position 79, and the problematic code is within the PostgreSQL
 database backend connection setup. The error originates from the
 'psycopg2' library, and the specific context points to a Unicode decoding
 problem in the 'data_handler.py' file. The error disrupts the migration
 process and prevents the successful execution of the command.

 Here is also Database Setting in  my  Django Project :

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'Databank',
 'USER': 'user',
 'PASSWORD': '123456',
 'HOST': 'localhost',
 'PORT': '5432',
 'OPTIONS': {
 'client_encoding': 'UTF8',
 }
 }
 }

--
-- 
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/0107018e0911f756-5c23f488-f219-41b1-9c8f-394a926aaeff-00%40eu-central-1.amazonses.com.

[Django] #35268: Error in Django Migration in PostgreSQL : UnicodeDecodeError during 'python manage.py migrate'

[Django]

#35268: Error in Django Migration in PostgreSQL  : UnicodeDecodeError during
'python manage.py migrate'
-+
   Reporter:  Azim1900   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  5.0
   Severity:  Normal |   Keywords:  PostgreSQL
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 When running the command 'python manage.py migrate' in a Django project, a
 UnicodeDecodeError occurs during the migration process.

  The error trace indicates that the issue is related to decoding a byte
 (0xbb) at position 79, and the problematic code is within the PostgreSQL
 database backend connection setup. The error originates from the
 'psycopg2' library, and the specific context points to a Unicode decoding
 problem in the 'vectordb_handler.py' file. The error disrupts the
 migration process and prevents the successful execution of the command.

 Here is also Database Setting in  my  Django Project :

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'Databank',
 'USER': 'user',
 'PASSWORD': '123456',
 'HOST': 'localhost',
 'PORT': '5432',
 'OPTIONS': {
 'client_encoding': 'UTF8',
 }
 }
 }
-- 
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/0107018e09112cbd-70b50418-91cc-411e-b3ad-78261616f235-00%40eu-central-1.amazonses.com.

Re: [Django] #35267: DateTimeField does not seem to be translated back to the local timezone on data retrieval on Postgres

[Django]

#35267: DateTimeField does not seem to be translated back to the local timezone 
on
data retrieval on Postgres
-+-
 Reporter:  Josh Smeaton |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm datetimefield| Triage Stage:
  timezones  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak):

 This is not a strict duplicate of #21214, but the discussion there should
 shed some light on the current behavior.
-- 
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/0107018e089be801-b0ef28ff-9b99-4c44-b2e5-d3c0f9f9af97-00%40eu-central-1.amazonses.com.