Re: Fellow Reports - December 2022
Week ending January 1, 2023 *Triaged: * https://code.djangoproject.com/ticket/34228 - Django 4.1.4 cannot import name 'force_unicode' from 'django.utils.encoding' (invalid) https://code.djangoproject.com/ticket/34229 - "no such column" when combining FilteredRelation and multi-table inheritance models (duplicate) https://code.djangoproject.com/ticket/34230 - Django templates shouldn't use a .html extension (invalid) https://code.djangoproject.com/ticket/34227 - Cyclic multi-level FilteredRelation with select_related() may set wrong related object. (accepted) https://code.djangoproject.com/ticket/34231 - Invalid RawSQL expression on Model.validate_constraints (invalid) https://code.djangoproject.com/ticket/34233 - Drop support for Python 3.8 & 3.9. (created) https://code.djangoproject.com/ticket/34234 - Drop support for PROJ < 5. (created) https://code.djangoproject.com/ticket/34235 - ManifestStaticFilesStorage should expose a "hash" of the manifest file. (accepted) *Reviewed/committed: * https://github.com/django/django/pull/16398 - Fixed #34226 -- Fixed QuerySet.select_related() with multiple FilteredRelations to the OneToOneField. https://github.com/django/django/pull/16405 - Fixed #34217 -- Fixed migration crash when removing check constraints on MySQL < 8.0.16. https://github.com/django/django/pull/14463 - Fixed #18468 -- Added support for comments on columns and tables. https://github.com/django/django/pull/16302 - Fixed #14094 -- Added support for unlimited models.CharField on PostgreSQL. https://github.com/django/django/pull/16407 - Upgraded OpenLayers to v.7.2.2. https://github.com/django/django/pull/16103 - Fixed #25617 -- Added case-insensitive unique username validation in UserCreationForm. https://github.com/django/django/pull/16413 - Refs #34100 -- Made file upload tests use Storage.exists() where appropriate. *Reviewed: * https://github.com/django/django/pull/16269 - Fixed #12075 -- Added wsgiorg.routing args support. *Authored: * https://github.com/django/django/pull/16406 - Disabled auto-created table of contents entries on Sphinx 5.2+. https://github.com/django/django/pull/16409 - Fixed #34208 -- Confirmed support for GDAL 3.6. https://github.com/django/django/pull/16412 - Fixed random delete.tests.DeletionTests.test_deletion_order failures. Best, Mariusz -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1e9eee24-2832-420e-9951-497a755c52a6n%40googlegroups.com.
Fellow Reports - January 2023
Week ending January 8, 2023 Released Django 4.1.5. Added https://code.djangoproject.com/wiki/Version5.0Roadmap. *Triaged: * https://code.djangoproject.com/ticket/34237 - FileField does not take upload_to into account when setting unique=True (invalid) https://code.djangoproject.com/ticket/34236 - Django logging when in production with Gunnicron (invalid) https://code.djangoproject.com/ticket/34238 - Support computed `GENERATED ALWAYS` columns (duplicate) https://code.djangoproject.com/ticket/31300 - Add function-based virtual fields. (accepted) https://code.djangoproject.com/ticket/34239 - Resolve load type-hinted objects in views (wontfix) https://code.djangoproject.com/ticket/33386 - Autocomplete on refresh with Firefox interacts badly with ModelMultipleChoiceField in forms (needsinfo) https://code.djangoproject.com/ticket/34240 - assertRedirects() doesn't preserve headers set in RequestFactory/Client methods. (created) https://code.djangoproject.com/ticket/34243 - timesince() raises TypeError with USE_TZ=True and >1 month interval. (accepted) https://code.djangoproject.com/ticket/34244 - Allow overriding error params in BaseValidator (wontfix) https://code.djangoproject.com/ticket/34241 - Django admin not showing seconds for list_display nor readonly DateTimeField (wontfix) *** **Reviewed/committed: * https://github.com/django/django/pull/16411 - Fixed #34235 -- Added ManifestFilesMixin.manifest_hash attribute. https://github.com/django/django/pull/16415 - Fixed #33783 -- Added IsEmpty GIS database function and __isempty lookup on PostGIS. https://github.com/django/django/pull/16360 - Fixed #34200 -- Made the session role configurable on PostgreSQL. https://github.com/django/django/pull/16401 - Refs #34074 -- Used headers argument for RequestFactory and Client in docs and tests. https://github.com/django/django/pull/16423 - Simplified django.utils.formats.date_format()/time_format() calls. https://github.com/django/django/pull/16425 - Fixed #34232 -- Fixed typo in docs/intro/tutorial07.txt. https://github.com/django/django/pull/16424 - Simplified implementation of various date formats. https://github.com/django/django/pull/16429 - Fixed #34243 -- Fixed timesince() crash with timezone-aware dates and interval longer than 1 month. https://github.com/django/django/pull/15872 - Fixed #33865 -- Optimized LimitedStream wrapper. https://github.com/django/django/pull/16433 - Fixed #34220 -- Moved csrf_input_lazy, csrf_token_lazy imports to the toplevel. https://github.com/django/django/pull/16434 - Renamed 'requests' test package. *Authored: * https://github.com/django/django/pull/16419 - Fixed #23842 -- Fixed flaky GeoQuerySetTest.test_make_line() test. https://github.com/django/django/pull/16430 - Refs #32355 -- Bumped mysqlclient requirement to >= 1.4.3. https://github.com/django/django/pull/16431 - Refs #32355 -- Bumped minimum supported versions of 3rd-party packages. Week ending January 15, 2023 *Triaged: * https://code.djangoproject.com/ticket/34245 - Change User model in BaseUserCreationForm/UserChangeForm.Meta to get_user_model(). (duplicate) https://code.djangoproject.com/ticket/34237 - FileField does not take upload_to into account when setting unique=True (invalid) https://code.djangoproject.com/ticket/34247 - Cannot resolve operation dependencies (needsinfo) https://code.djangoproject.com/ticket/34249 - Custom RelatedManager documentation should have side tip on prefetch_related (duplicate) https://code.djangoproject.com/ticket/34250 - Duplicate model names in M2M relationship causes RenameModel migration failure (accepted) https://code.djangoproject.com/ticket/34255 - Annotation/group by with an expression on psycopg3 (accepted) https://code.djangoproject.com/ticket/34256 - There is a problem in the document (invalid) https://code.djangoproject.com/ticket/34258 - Import Error issues. (duplicate) https://code.djangoproject.com/ticket/34257 - ForeignKeyRawIdWidget doesn't include vForeignKeyRawIdAdminField class when custom class passed in attrs (wontfix) *Reviewed/committed: * https://github.com/django/django/pull/16321 - Fixed #34176 -- Fixed grouping by ambiguous aliases. https://github.com/django/django/pull/16437 - Refs #30240 -- Fixed argument name for MySQLSHA2Mixin.as_mysql() and PostgreSQLSHAMixin.as_postgresql() methods. https://github.com/django/django/pull/16262 - Fixed #34110 -- Added in-memory file storage. https://github.com/django/django/pull/16428 - Fixed #31014 -- Added FromWKB and FromWKT GIS database functions. https://github.com/django/django/pull/16441 - Refs #26029 -- Added LazySettings._show_deprecation_warning() hook. https://github.com/django/django/pull/16442 - Fixed #26029 -- Allowed configuring custom file storage backends. https://github.com/django/django/pull/15610 - Refs #26029 -- Deprecated DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings. https://github.com/django/django/pull/16445 - Fixed #34234 -- Droppe
Re: Proposal for an "Age" PostgreSQL ORM function
Am 19.01.23 um 21:14 schrieb Jason Johns: the AGE function takes in two timestamps and returns an interval. You can do this in python by subtracting two date/datetime objects and getting a timedelta. what would the difference be to kick this out to the db? I'd say thats mainly about performance - the DB can almost almost always calculate things much more efficiently, eg. for AGE with table data: - less datapoints to be moved to client side (should run ~2x faster here, if the mangling of datetime and range type is equally expensive) - Ideally the db has a fast impl for the function, thus the calculation loop would also run faster than in python / on django side. Since I have not benchmarked AGE this is all speculative (TM), but there is a good chance to get at least a 2x faster processing. Furthermore this is also about SQL realms vs. client roundtrips & deduplication - a value calculated on python side cannot be used in SQL directly anymore, you either need another python roundtrip to calc the values and put it back to DB side or some data duplication on a table (eww, now you've violated the normalization rules). Still all that is not yet a good indicator, whether AGE should be supported natively, as there is more to it from ORM perspective: - Is AGE a vivid use case, does it help django users to get things done? - Whats the testing/maintenance burden of AGE? - How about other DB vendors? Now to the downsides of AGE in postgres itself - it creates a "symbolic" range string in years|months|days, rather than in postgres' standard interval repr. This might create frictions at the interval to timedelta translation in psycopg*, at least needs extensive testing for edge cases, that might occur in that weird "symbolic" notation. That uncertainty is a very bad startpoint for an ORM to get reliable functionality and def. raises the test/maintenance needs just for that AGE function. An in-depth analysis of all these points might reveal, that its more reliable to just use datetime substraction at SQL level. Which is already easy doable and prolly also works with many other DB vendors. Which again somewhat questions the idea for native postgres AGE support. In summary - I am not against an ORM age thingy, still think that a more general impl covering other vendors as well might be more helpful. Cheers, Jerch [*] Again speculative (TM) - I know that Daniele Varrazzo does a really great job in maintaining psycopg and it prolly will just work as expected. It still creates a dependency on a less often used/tested code path, so needs more caution on ORM side. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/99882add-3d8b-16a7-af28-6316a384c45a%40netzkolchose.de.
Re: Proposal for an "Age" PostgreSQL ORM function
>From the maintenance perspective, it's not that any one individual function is too hard to maintain — it's clearly not. Rather it's about not adding a million of them — which would add up — and in so doing essentially duplicating the entire API offered by databases. * Each one we add makes the docs longer, and less fun to read. Every user has to answer (for each one) "What's this?" and "Is it relevant to me?" * Once you get beyond the core functions they impose that cost with less and less likelihood of being relevant. * And the function wrappers are in the main really quite trivial to add to your own project if you want them. Previous discussions have more or less pointed to the core cases being covered, and not adding a whole lot more. (There's always the possibility that one extra **is** worth adding, but …) One question: > the function wrappers are in the main really quite trivial to add to your own project if you want them. Can we make the docs point this out more clearly? Like custom fields, custom functions shouldn't be something folks shy away from. 🤔 Kind Regards, Carlton On Friday, 20 January 2023 at 13:44:57 UTC+1 j.bre...@netzkolchose.de wrote: > > > Am 19.01.23 um 21:14 schrieb Jason Johns: > > the AGE function takes in two timestamps and returns an interval. You > > can do this in python by subtracting two date/datetime objects and > > getting a timedelta. what would the difference be to kick this out to > > the db? > > I'd say thats mainly about performance - the DB can almost almost always > calculate things much more efficiently, eg. for AGE with table data: > - less datapoints to be moved to client side (should run ~2x faster > here, if the mangling of datetime and range type is equally expensive) > - Ideally the db has a fast impl for the function, thus the calculation > loop would also run faster than in python / on django side. > > Since I have not benchmarked AGE this is all speculative (TM), but there > is a good chance to get at least a 2x faster processing. > > Furthermore this is also about SQL realms vs. client roundtrips & > deduplication - a value calculated on python side cannot be used in SQL > directly anymore, you either need another python roundtrip to calc the > values and put it back to DB side or some data duplication on a table > (eww, now you've violated the normalization rules). > > Still all that is not yet a good indicator, whether AGE should be > supported natively, as there is more to it from ORM perspective: > - Is AGE a vivid use case, does it help django users to get things done? > - Whats the testing/maintenance burden of AGE? > - How about other DB vendors? > > Now to the downsides of AGE in postgres itself - it creates a "symbolic" > range string in years|months|days, rather than in postgres' standard > interval repr. This might create frictions at the interval to timedelta > translation in psycopg*, at least needs extensive testing for edge > cases, that might occur in that weird "symbolic" notation. That > uncertainty is a very bad startpoint for an ORM to get reliable > functionality and def. raises the test/maintenance needs just for that > AGE function. > > An in-depth analysis of all these points might reveal, that its more > reliable to just use datetime substraction at SQL level. Which is > already easy doable and prolly also works with many other DB vendors. > Which again somewhat questions the idea for native postgres AGE support. > > In summary - I am not against an ORM age thingy, still think that a more > general impl covering other vendors as well might be more helpful. > > Cheers, > Jerch > > > [*] Again speculative (TM) - I know that Daniele Varrazzo does a really > great job in maintaining psycopg and it prolly will just work as > expected. It still creates a dependency on a less often used/tested code > path, so needs more caution on ORM side. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a46517dd-a03f-47e6-bdd6-4a052e6bdaecn%40googlegroups.com.
New contributor
Hi Every One, I want to contribute. Please assign me a task or issue. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbcdb59c-f17b-4bb8-8212-ab1d36df7ea4n%40googlegroups.com.
