Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

[Django]

#33346: assertFormsetError() crashes on formset named "form".
---+
 Reporter:  OutOfFocus4|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by 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/069.a12c61512f3681dc82e80680201051c2%40djangoproject.com.

Re: [Django] #33346: assertFormsetError() crashes on formset named "form". (was: Form rendering in Django 4 causes AttributeError during testing)

[Django]

#33346: assertFormsetError() crashes on formset named "form".
---+--
 Reporter:  OutOfFocus4|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * cc: David Smith (added)
 * component:  Forms => Testing framework
 * severity:  Normal => Release blocker


Comment:

 Thanks for the report, it's niche but we should definitely fix this bug in
 `assertFormsetError()`.

 Regression in 456466d932830b096d39806e291fe23ec5ed38d5.

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

Re: [Django] #33345: Forms does not search external template directories

[Django]

#33345: Forms does not search external template directories
-+-
 Reporter:  Guillaume|Owner:  nobody
  Quenneville|
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  template discovery   | Triage Stage:
  forms  |  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: David Smith (added)
 * status:  new => closed
 * resolution:   => invalid


Comment:

 `Form.render()` uses
 
[https://docs.djangoproject.com/en/4.0/ref/forms/api/#django.forms.Form.default_renderer
 Form.default_renderer] when the `renderer` argument is not specified, and
 `Form.default_renderer` defaults to the
 [https://docs.djangoproject.com/en/4.0/ref/settings/#std:setting-
 FORM_RENDERER FORM_RENDERER] setting which defaults to
 
[https://docs.djangoproject.com/en/4.0/ref/forms/renderers/#django.forms.renderers.DjangoTemplates
 `'django.forms.renderers.DjangoTemplates'`]. If you want to render
 templates with customizations from your `TEMPLATES` setting, you should
 change the renderer to use the
 
[https://docs.djangoproject.com/en/4.0/ref/forms/renderers/#django.forms.renderers.TemplatesSetting
 `TemplatesSetting`] renderer at any of these levels.

-- 
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/078.e04115f0892204fba1ebbde6a1829e89%40djangoproject.com.

Re: [Django] #33345: Forms does not search external template directories

[Django]

#33345: Forms does not search external template directories
-+-
 Reporter:  Guillaume|Owner:  nobody
  Quenneville|
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  template discovery   | Triage Stage:
  forms  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Guillaume Quenneville):

 * cc: Guillaume Quenneville (added)
 * component:  Template system => Forms


-- 
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/078.f60b7073573e19364db4f0095387187e%40djangoproject.com.

Re: [Django] #33346: Form rendering in Django 4 causes AttributeError during testing

[Django]

#33346: Form rendering in Django 4 causes AttributeError during testing
-+--
 Reporter:  OutOfFocus4  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  4.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 OutOfFocus4):

 * Attachment "example.zip" added.

 Basic Django application to demonstrate the bug. Just install Django 4 and
 run "manage.py test"

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

Re: [Django] #33346: Form rendering in Django 4 causes AttributeError during testing

[Django]

#33346: Form rendering in Django 4 causes AttributeError during testing
-+--
 Reporter:  OutOfFocus4  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  4.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 OutOfFocus4):

 * Attachment "example.zip" added.

 Basic Django application to demonstrate the bug. Just install Django 4 and
 run "manage.py test"

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

[Django] #33346: Form rendering in Django 4 causes AttributeError during testing

[Django]

#33346: Form rendering in Django 4 causes AttributeError during testing
---+
   Reporter:  OutOfFocus4  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Forms|Version:  4.0
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I started updating a project from Django 3 to Django 4. When I ran my unit
 tests after the update, one of them failed with an AttributeError.

 The full stack trace is

 {{{
 Traceback (most recent call last):
   File "/private/tmp/example/example/tests.py", line 17, in test_formset
 self.assertFormsetError(
   File "/private/tmp/example/.venv/lib/python3.9/site-
 packages/django/test/testcases.py", line 565, in assertFormsetError
 if field in context[formset].forms[form_index].errors:
 AttributeError: 'ManagementForm' object has no attribute 'forms'
 }}}

 It looks like rendering the ManagementForm of a formset adds a context to
 response.context which contains a "form". Calling "assertFormsetError" to
 check for errors in a formset called "form" will check the formset's
 errors, but will also try to look at the errors in any "form" in all
 contexts, including the ManagementForm.

-- 
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/054.5c356cc512edd448f5df423df9bf1968%40djangoproject.com.

Re: [Django] #33344: Define bounds transform for discrete postgres range fields

[Django]

#33344: Define bounds transform for discrete postgres range fields
-+-
 Reporter:  Vidir Valberg|Owner:  (none)
  Gudmundsson|
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Vidir Valberg Gudmundsson):

 Replying to [comment:4 Mariusz Felisiak]:
 > Moreover this can be confusing for users who will assume that values are
 stored with different bounds.

 Yeah, that I can agree on. That's also why I want to somehow name the
 feature along the lines of "transform", "cast" og maybe "output". Also the
 default would be "[)" thus only something one would set if one wanted to
 change the output 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/065.82af67751c8ea63669c472f9db6b7e6f%40djangoproject.com.

Re: [Django] #33344: Define bounds transform for discrete postgres range fields

[Django]

#33344: Define bounds transform for discrete postgres range fields
-+-
 Reporter:  Vidir Valberg|Owner:  (none)
  Gudmundsson|
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Vidir Valberg Gudmundsson):

 Replying to [comment:3 Mariusz Felisiak]:
 > Thanks for this ticket, however it's not clear for me what do you want
 to achieve. Bounds cannot be specify for discrete range types because they
 are not natively supported on PostgreSQL. I don't think we should add
 implicit logic in our fields to give the impression that they are, this
 looks error-prone and it's probably not worth the complexity.

 Fair enough - although I want to try to motivate it some more to try to
 see if there is any way we can solve this problem:

 1. I have a date range 2021-01-01 to 2021-01-31.
 2. I want to save this in postgresql (in a `DateRangeField`), thus doing:
 {{{
 >>> foo.period = DateRange(lower=date(2021, 1, 1), upper=date(2021, 1,
 31), bounds="[]")
 }}}
 3. We retrieving this from the database it comes back as
 {{{
 >>> foo.period
 DateRange(lower=date(2021, 1, 1), upper=date(2021, 2, 1), bounds="[)")
 }}}
 4. So when I want to represent this in, say, a template, I have to
 explicitly do the following every time I want to access the upper field.
 {{{
 foo.period.upper - timedelta(day=1)
 }}}

 So my goal is not to specify the bounds going into postgres, but only how
 the data coming out is represented. Hence the naming of `bounds_transform`
 (I started calling it `bounds_cast`).

 Does this make my goal more clear?

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

Re: [Django] #33344: Define bounds transform for discrete postgres range fields

[Django]

#33344: Define bounds transform for discrete postgres range fields
-+-
 Reporter:  Vidir Valberg|Owner:  (none)
  Gudmundsson|
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Moreover this can be confusing for users who will assume that values are
 stored with different bounds.

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

Re: [Django] #25265: DB Backend cannot specify query class.

[Django]

#25265: DB Backend cannot specify query class.
-+-
 Reporter:  Samuel Bishop|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"547656c85027eda85a24edcab907022ce313f772" 547656c8]:
 {{{
 #!CommitTicketReference repository=""
 revision="547656c85027eda85a24edcab907022ce313f772"
 Refs #25265 -- Allowed customizing Query's datastructure classes.
 }}}

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

Re: [Django] #33344: Define bounds transform for discrete postgres range fields

[Django]

#33344: Define bounds transform for discrete postgres range fields
-+-
 Reporter:  Vidir Valberg|Owner:  (none)
  Gudmundsson|
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  dev
 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):

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


Comment:

 Thanks for this ticket, however it's not clear for me what do you want to
 achieve. Bounds cannot be specify for discrete range types because they
 are not natively supported on PostgreSQL. I don't think we should add
 implicit logic in our fields to give the impression that they are, this
 looks error-prone and it's probably not worth the complexity.

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

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 Daniel Hahler):

 Sorry for not having read the mailing list thread yet, but only your
 summary of it above.
 I think the main issue with context vs. cause is an important detail.  I
 can see that it might not worth changing it all over the code base, but it
 should be considered when fixing code.

 The main issue I see here is that there will be an exception almost always
 (at least with named cursors in PostgreSQL AFAICS), and therefore it
 should not even be chained in this case: it really just hides the actual
 error, just because it is trying to ensure a (never properly opened/used)
 cursor is closed always.

 I might follow up on the mailing list, but do not really feel like
 subscribing there also etc, especially since the issue here is not about
 context or cause, but only using `raise from` properly (according to
 https://blog.ram.rachum.com/post/621791438475296768/improving-python-
 exception-chaining-with) when not swallowing/hiding the expected
 exception.

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

[Django] #33345: Forms does not search external template directories

[Django]

#33345: Forms does not search external template directories
-+-
   Reporter:  Guillaume  |  Owner:  nobody
  Quenneville|
   Type:  Bug| Status:  new
  Component:  Template   |Version:  4.0
  system |   Keywords:  template discovery
   Severity:  Normal |  forms
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 It seems like the new form templates ignores external template
 directories? (or I did something silly). It works for app's local template
 directory.

 I created a test repo
 https://github.com/GuillaumeQuenneville/djangoform.git

 Django finds home.html (parent template) but does not find the
 item_form.html template in the same dir.

 Adding the form template to the test app's local templates folder fixes
 the discovery issue (rename item_form.html.bk -> item_form.html in repo)

 As a test, I turned on the debugger before the render in the view. Calling
 render(request, 'home.html') returns a 200 and no error, calling
 form.render(template_name='home.html') says home.html not found, idem for
 form.render() saying item_form.html not found. So there is a difference in
 template discovery??

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

Re: [Django] #33344: Define bounds transform for discrete postgres range fields

[Django]

#33344: Define bounds transform for discrete postgres range fields
-+-
 Reporter:  Vidir Valberg|Owner:  (none)
  Gudmundsson|
 Type:  New feature  |   Status:  new
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Vidir Valberg Gudmundsson:

Old description:

> The fix for https://code.djangoproject.com/ticket/27147 adressed the
> issue of non-discrete range types. Left is the issue of how the ranges
> are "represented" when brought back from the database.
>
> At $WORK we have a model like so:
>
> {{{
> class Foo(models.Model):
> ...
> period = models.DateRangeField()
> }}}
>

>
> The problem arises when we display the periods of multiple `Foo`s. Using
> the default bound of `[)` returned by postgres means that adjacent `Foo`s
> "visually" share a date in the upper of one and lower of the other. We
> could of course handle this ''each time'' we output the value by
> decrementing the upper value. But this is a bit error prone and can lead
> to confusions.
>
> I propose that we add something in the lines of the following to
> `django.contrib.postres.fields.ranges` (heavily inspired by Jakub
> Skałeckis comment at
> https://code.djangoproject.com/ticket/27147#comment:8):
>
> {{{
> class DiscreteRangeField(RangeField):
>
> def __init__(self, *args, bounds_transform=CANONICAL_RANGE_BOUNDS,
> **kwargs):
> if bounds_transform not in ALLOWED_BOUNDS:
> raise ValueError("bounds_transform must be one of '[)', '(]',
> '()', or '[]'.")
> self.bounds_transform = bounds_transform
> super().__init__(*args, **kwargs)
>
> def from_db_value(self, value, expression, connection):
> if value is None:
> return
>
> if self.bounds_transform[0] == "(" and value.lower:
> value._lower = value.lower - self.bounds_transform_unit
>
> if self.bounds_transform[1] == "]" and value.upper:
> value._lower = value.upper - self.bounds_transform_unit
>
> value._bounds = self.bounds_transform
> return value
> }}}
>
> and make `IntegerRangeField`, `BigIntegerRangeField` and `DateRangeField`
> inherit from `DiscreteRangeField`.
>
> I have already written some tests, and if there are no big gotchas to
> this approach I would love to submit a PR in the next couple of days.

New description:

 The fix for https://code.djangoproject.com/ticket/27147 adressed the issue
 of non-discrete range types. Left is the issue of how the ranges are
 "represented" when brought back from the database.

 At $WORK we have a model like so:

 {{{
 class Foo(models.Model):
 ...
 period = models.DateRangeField()
 }}}



 The problem arises when we display the periods of multiple `Foo`s. Using
 the default bound of `[)` returned by postgres means that adjacent `Foo`s
 "visually" share a date in the upper of one and lower of the other. We
 could of course handle this ''each time'' we output the value by
 decrementing the upper value. But this is a bit error prone and can lead
 to confusions.

 I propose that we add something along the lines of the following to
 `django.contrib.postres.fields.ranges` (heavily inspired by Jakub
 Skałeckis comment at
 https://code.djangoproject.com/ticket/27147#comment:8):

 {{{
 class DiscreteRangeField(RangeField):

 def __init__(self, *args, bounds_transform=CANONICAL_RANGE_BOUNDS,
 **kwargs):
 if bounds_transform not in ALLOWED_BOUNDS:
 raise ValueError("bounds_transform must be one of '[)', '(]',
 '()', or '[]'.")
 self.bounds_transform = bounds_transform
 super().__init__(*args, **kwargs)

 def from_db_value(self, value, expression, connection):
 if value is None:
 return

 if self.bounds_transform[0] == "(" and value.lower:
 value._lower = value.lower - self.bounds_transform_unit

 if self.bounds_transform[1] == "]" and value.upper:
 value._lower = value.upper - self.bounds_transform_unit

 value._bounds = self.bounds_transform
 return value
 }}}

 and make `IntegerRangeField`, `BigIntegerRangeField` and `DateRangeField`
 inherit from `DiscreteRangeField`.

 I have already written some tests, and if there are no big gotchas to this
 approach I would love to submit a PR in the next couple of days.

--

-- 
Ticket URL: 

Re: [Django] #33344: Define bounds transform for discrete postgres range fields

[Django]

#33344: Define bounds transform for discrete postgres range fields
-+-
 Reporter:  Vidir Valberg|Owner:  (none)
  Gudmundsson|
 Type:  New feature  |   Status:  new
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Vidir Valberg Gudmundsson:

Old description:

> The fix for https://code.djangoproject.com/ticket/27147 adressed the
> issue of non-discrete range types. Left is the issue of how the ranges
> are "represented" when brought back from the database.
>
> At $WORK we have a model like so:
>
> {{{
> class Foo(models.Model):
> ...
> period = models.DateRangeField()
> }}}
>

>
> The problem arises when we display the periods of multiple `Foo`s. Using
> the default bound of `[)` returned by postgres means that adjacent `Foo`s
> "visually" share a date in the upper of one and lower of the other. We
> could of course handle this ''each time'' we output the value by
> decrementing the upper value. But this is a bit error prone and can lead
> to confusions.
>
> I propose that we add the following to
> `django.contrib.postres.fields.ranges` (heavily inspired by Jakub
> Skałeckis comment at
> https://code.djangoproject.com/ticket/27147#comment:8):
>
> {{{
> class DiscreteRangeField(RangeField):
>
> def __init__(self, *args, bounds_transform=CANONICAL_RANGE_BOUNDS,
> **kwargs):
> if bounds_transform not in ALLOWED_BOUNDS:
> raise ValueError("bounds_transform must be one of '[)', '(]',
> '()', or '[]'.")
> self.bounds_transform = bounds_transform
> super().__init__(*args, **kwargs)
>
> def from_db_value(self, value, expression, connection):
> if value is None:
> return
>
> if self.bounds_transform[0] == "(" and value.lower:
> value._lower = value.lower - self.bounds_transform_unit
>
> if self.bounds_transform[1] == "]" and value.upper:
> value._lower = value.upper - self.bounds_transform_unit
>
> value._bounds = self.bounds_transform
> return value
> }}}
>
> and make `IntegerRangeField`, `BigIntegerRangeField` and `DateRangeField`
> inherit from `DiscreteRangeField`.
>
> I have already written some tests, and if there are no big gotchas to
> this approach I would love to submit a PR in the next couple of days.

New description:

 The fix for https://code.djangoproject.com/ticket/27147 adressed the issue
 of non-discrete range types. Left is the issue of how the ranges are
 "represented" when brought back from the database.

 At $WORK we have a model like so:

 {{{
 class Foo(models.Model):
 ...
 period = models.DateRangeField()
 }}}



 The problem arises when we display the periods of multiple `Foo`s. Using
 the default bound of `[)` returned by postgres means that adjacent `Foo`s
 "visually" share a date in the upper of one and lower of the other. We
 could of course handle this ''each time'' we output the value by
 decrementing the upper value. But this is a bit error prone and can lead
 to confusions.

 I propose that we add something in the lines of the following to
 `django.contrib.postres.fields.ranges` (heavily inspired by Jakub
 Skałeckis comment at
 https://code.djangoproject.com/ticket/27147#comment:8):

 {{{
 class DiscreteRangeField(RangeField):

 def __init__(self, *args, bounds_transform=CANONICAL_RANGE_BOUNDS,
 **kwargs):
 if bounds_transform not in ALLOWED_BOUNDS:
 raise ValueError("bounds_transform must be one of '[)', '(]',
 '()', or '[]'.")
 self.bounds_transform = bounds_transform
 super().__init__(*args, **kwargs)

 def from_db_value(self, value, expression, connection):
 if value is None:
 return

 if self.bounds_transform[0] == "(" and value.lower:
 value._lower = value.lower - self.bounds_transform_unit

 if self.bounds_transform[1] == "]" and value.upper:
 value._lower = value.upper - self.bounds_transform_unit

 value._bounds = self.bounds_transform
 return value
 }}}

 and make `IntegerRangeField`, `BigIntegerRangeField` and `DateRangeField`
 inherit from `DiscreteRangeField`.

 I have already written some tests, and if there are no big gotchas to this
 approach I would love to submit a PR in the next couple of days.

--

-- 
Ticket URL: 

[Django] #33344: Define bounds transform for discrete postgres range fields

[Django]

#33344: Define bounds transform for discrete postgres range fields
-+-
   Reporter:  Vidir  |  Owner:  (none)
  Valberg Gudmundsson|
   Type:  New| Status:  new
  feature|
  Component: |Version:  dev
  contrib.postgres   |
   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  |
-+-
 The fix for https://code.djangoproject.com/ticket/27147 adressed the issue
 of non-discrete range types. Left is the issue of how the ranges are
 "represented" when brought back from the database.

 At $WORK we have a model like so:

 {{{
 class Foo(models.Model):
 ...
 period = models.DateRangeField()
 }}}



 The problem arises when we display the periods of multiple `Foo`s. Using
 the default bound of `[)` returned by postgres means that adjacent `Foo`s
 "visually" share a date in the upper of one and lower of the other. We
 could of course handle this ''each time'' we output the value by
 decrementing the upper value. But this is a bit error prone and can lead
 to confusions.

 I propose that we add the following to
 `django.contrib.postres.fields.ranges` (heavily inspired by Jakub
 Skałeckis comment at
 https://code.djangoproject.com/ticket/27147#comment:8):

 {{{
 class DiscreteRangeField(RangeField):

 def __init__(self, *args, bounds_transform=CANONICAL_RANGE_BOUNDS,
 **kwargs):
 if bounds_transform not in ALLOWED_BOUNDS:
 raise ValueError("bounds_transform must be one of '[)', '(]',
 '()', or '[]'.")
 self.bounds_transform = bounds_transform
 super().__init__(*args, **kwargs)

 def from_db_value(self, value, expression, connection):
 if value is None:
 return

 if self.bounds_transform[0] == "(" and value.lower:
 value._lower = value.lower - self.bounds_transform_unit

 if self.bounds_transform[1] == "]" and value.upper:
 value._lower = value.upper - self.bounds_transform_unit

 value._bounds = self.bounds_transform
 return value
 }}}

 and make `IntegerRangeField`, `BigIntegerRangeField` and `DateRangeField`
 inherit from `DiscreteRangeField`.

 I have already written some tests, and if there are no big gotchas to this
 approach I would love to submit a PR in the next couple of days.

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

Re: [Django] #23577: Rename operations should rename indexes, constraints, sequences and triggers named after their former value

[Django]

#23577: Rename operations should rename indexes, constraints, sequences and
triggers named after their former value
-+
 Reporter:  Chris Woytowitz  |Owner:  (none)
 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
-+
Changes (by Daniel Hahler):

 * cc: Daniel Hahler (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/068.85748499c2e3c3700ca9b8b9e3b9912a%40djangoproject.com.

Re: [Django] #33279: Time zones with minus in names are incorrectly converted.

[Django]

#33279: Time zones with minus in names are incorrectly converted.
-+-
 Reporter:  yakimka  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:9 yakimka]:
 > This fix was not added to version 3.2.10 by mistake?

 It's a regression in Django 3.0, per our backporting policy this means it
 doesn't qualify for a backport to 3.2.x anymore. See
 [https://docs.djangoproject.com/en/stable/internals/release-process/
 Django’s release process] for more details.

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

Re: [Django] #33279: Time zones with minus in names are incorrectly converted.

[Django]

#33279: Time zones with minus in names are incorrectly converted.
-+-
 Reporter:  yakimka  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yakimka):

 This fix was not added to version 3.2.10 by mistake?

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

Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

[Django]

#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 GitHub ):

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


Comment:

 In [changeset:"063cf98d3a6839f40c423cbd845def429c5cf0ce" 063cf98]:
 {{{
 #!CommitTicketReference repository=""
 revision="063cf98d3a6839f40c423cbd845def429c5cf0ce"
 Fixed #31765 -- Enforced enhanced ALTER TABLE behavior for SQLite
 connections.
 }}}

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