Fellow Report - March 26, 2016
Triaged --- https://code.djangoproject.com/ticket/26386 - ManifestStaticFilesStorage not respecting commented lines in collect static (duplicate) https://code.djangoproject.com/ticket/26381 - UserCreationForm cannot be reused with a custom USERNAME_FIELD value (fixed) https://code.djangoproject.com/ticket/26382 - Better decouple Storage and FileField (duplicate) https://code.djangoproject.com/ticket/26372 - admin_order_field ignored when shadowing model field (accepted) https://code.djangoproject.com/ticket/26384 - Django 1.9 regression in migrations due to lazy model operations refactor (accepted) https://code.djangoproject.com/ticket/26385 - Squashing migrations with Python 2.7 adds bytestring prefix to ManyToManyField 'to' values which fails to run on Python 3 (accepted) https://code.djangoproject.com/ticket/26379 - Inconsistent behaviour of filter() on related model (RelatedManager) (accepted) https://code.djangoproject.com/ticket/26387 - Related popup doesn’t open in a changelist when list_editable in raw_id_fields (accepted) https://code.djangoproject.com/ticket/26388 - make is_anonymous and is_authenticated properties (duplicate) https://code.djangoproject.com/ticket/26392 - Sample code for @permission_required is incorrect (fixed) https://code.djangoproject.com/ticket/26395 - CryptPasswordHasher only return None on some platform (fixed) https://code.djangoproject.com/ticket/26393 - Unable to filter against annotations in Manager with use_for_related_fields (wontfix) https://code.djangoproject.com/ticket/26397 - Use custom managers on Foreign Key (duplicate) https://code.djangoproject.com/ticket/26404 - Change of primary key field does not update foreign keys in migration (duplicate) https://code.djangoproject.com/ticket/26405 - ModelMultipleChoiceField does not honor to_field_name at render (duplicate) Authored https://github.com/django/django/pull/6327 - Split model_fields tests into different files. https://github.com/django/django/pull/6332 - Fixed #26387 -- Restored the functionality of the admin's raw_id_fields in list_editable. Reviewed/committed -- https://github.com/django/django/pull/6308 - Fixed #26365 --- Added a system check to ensure "string_is_invalid" is a string https://github.com/django/django/pull/6192 - Fixed #26235 -- Handled ProtectedError in a POST to admin's delete_view(). https://github.com/django/django/pull/6316 - Fixed #26378 -- Allowed a left byte of zero in mixed IPv4/IPv6 validation. https://github.com/django/django/pull/6312 - Fixed #26293 -- Fixed CommonMiddleware to process PREPEND_WWW and APPEND_SLASH independently. https://github.com/django/django/pull/6325 - Fixed #26398 -- Made FieldFile.open() respect its mode argument. https://github.com/django/django/pull/6302 - Fixed #25759 -- Added keyword arguments to customize Expressions' as_sql(). https://github.com/django/django/pull/6271 - Fixed #24932 -- Added Cast database function. Reviews of core dev work https://github.com/django/django/pull/6333 - Fixed #25987 -- Made inline formset validation respect unique_together with an unsaved parent object. https://github.com/django/django/pull/6236 - Fixed #24227 -- Replaced ForeignKey isinstance checks by field.many_to_one. -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ae3925bb-ceff-4dc9-806f-c3099bb61d24%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal on Custom Indexes - Google Summer of Code
> > > That is a bit too strict; sometimes it does make sense to provide more > than > one kind of index on one field. As a trivial example, you may want to > support > case-sensitive uniqueness as well as case-insensitive search (say, for > user- > names). > Ohh yes definitely, I meant no two identical indexes on the same field. Sorry for the wrong choice of words. -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/119f21bf-b6fa-480c-a100-d779c7092a5f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal on Custom Indexes - Google Summer of Code
On Monday 14 March 2016 12:15:33 akki wrote: > > you can't have identical indexes defined in multiple ways with the same > > names. > > Yes, I will be checking for the duplications at the autodetector level > itself. We need to take care that no two indexes are for the same fields, > and none of them have a clashing name. On such an occurrence, we can raise > an error like "Multiple indexes have been set for 'field1' " or merge them > ourself internally (if they mean exactly the same). That is a bit too strict; sometimes it does make sense to provide more than one kind of index on one field. As a trivial example, you may want to support case-sensitive uniqueness as well as case-insensitive search (say, for user- names).
Re: Value of tightening URLValidator/EmailValidator regular expressions?
On Tuesday 15 March 2016 04:51:50 Markus Holtermann wrote: > > WRT the backwards compatibility issues: > > 2) You're not able to submit an email address that does not pass the new > validator but the old one. --> Unlikely, but when the new field is of > type="email" your rather modern browser will tell you before Django > anyway > While this is correct, in many of your rather modern web applications Django does not own the front-end, and for web services, a relevant front end doesn't even necessarily exist. So the backward-incompatibility is not horrible, but it exists and needs to be mitigated by a deprecation cycle. Shai
