Fellow Report - August 26, 2017

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/28513 - LogoutView doesn't support 
POST, unlike the function-based logout() view (accepted)

https://code.djangoproject.com/ticket/28514 - Clarify docs regarding 
idempotence of RelatedManager.add() (accepted)

https://code.djangoproject.com/ticket/28515 - mysql is checking all models 
also models that are mapped to POSTGIS (invalid) 

https://code.djangoproject.com/ticket/28506 - Ease hooking custom views to 
the Django admin (duplicate)

https://code.djangoproject.com/ticket/28501 - "python -m django runserver" 
crashes (accepted)

https://code.djangoproject.com/ticket/28521 - Align checkboxes under other 
field inputs in Django admin (wontfix)

https://code.djangoproject.com/ticket/28473 - Consider SCRIPT_NAME for 
SECURE_REDIRECT_EXEMPT setting (accepted)

https://code.djangoproject.com/ticket/28516 - Admin change_list logs 
multiple "VariableDoesNotExist" errors. (duplicate)

https://code.djangoproject.com/ticket/28526 - Remedy verbose, often 
unhelpful undefined tempate variable logging (created)

https://code.djangoproject.com/ticket/28531 - MultipleChoiceField / 
CheckboxSelectMultiple values linked to a CharField not restored on bound 
model forms (duplicate)

Reviewed/committed

--

https://github.com/django/django/pull/8903 - Fixed #28496 -- Added 
ModelAdmin.get_changelist_instance().

https://github.com/django/django/pull/8950 - Fixed #28498 -- Added support 
for cx_Oracle 6.

https://github.com/django/django/pull/8898 - Fixed #28451 -- Restored 
pre-Django 1.11 Oracle sequence/trigger naming.

https://github.com/django/django/pull/8901 - Fixed #27931 -- Clarified the 
meaning of "django catch-all logger."

https://github.com/django/django/pull/8939 - Fixed #27796 -- Prevented 
middleware being loaded twice with runserver.

https://github.com/django/django/pull/8725 - Fixed #28380 -- Excluded null 
geometries in SpatiaLite geometry lookups.

https://github.com/django/django/pull/8964 - Fixed #28513 -- Added POST 
request support to LogoutView.
https://github.com/django/django/pull/8956 - Fixed #28518 -- Improved 
performance of loading geometries from DB.

-- 
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/d275d944-d40c-427d-96cc-ff3cf949aeea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

[Collin Anderson]

Hi All,

I have a pull request for simple add()/create() etc with m2m through tables
if any wants to try it out: https://github.com/django/django/pull/8981

If people are happy with the API, I'll add the docs too.

Collin


On Mon, Apr 17, 2017 at 3:53 PM, Luis Masuelli 
wrote:

> I'm quite happy to see the topic is at least being considered! <3.
>
> Although I suggested a solution, I like the solution posted by Collin in
> the PR (I'd prefer solutions not involving signature changes in methods,
> but anyway those signature changes Colin posted are not so... obtrusive).
>
> I'd like to, however, propose a little change in Collin's code.
> Immediately before this code in _add_items:
>
> self.through(**dict(through_defaults, **{
> '%s_id' % source_field_name:
> self.related_val[0],
> '%s_id' % target_field_name: obj_id,
> }))
>
> This one:
>
> if callable(through_defaults):
> through_defaults =
> through_defaults(self.related_val[0], obj_id)
>
> With these two lines, we could allow passing a callable to through_fields
> (as we pass callables for defaults in django fields). The return value of
> such callable should be a dictionary, while the arguments should be source
> and target ids.
>
> But even if this little change is not implemented, I like the Collin's
> solution anyway.
>
> Another subtopic to discuss is about enhancing the Collin's solution, is
> to allow through_defaults be specified on field definition (In the same way
> we define default values in... scalar... fields; I leave open the
> discussion on whether such value should be overriden when using add,
> create, or any of these methods as changed by Collin).
>
> I like how this is going and hope that any solution (even if it is just
> the as-is solution provided by Collin, with no changes) be accepted in any
> near-future version <3.
>
> El martes, 21 de marzo de 2017, 20:29:33 (UTC-5), Alex Hill escribió:
>>
>> Here's a little bit more historical discussion on the topic: 
>> *https://groups.google.com/d/topic/django-developers/uWe31AjzZX0/discussion
>> *
>>
>> On Wed, 22 Mar 2017 at 05:57 Russell Keith-Magee 
>> wrote:
>>
>>> On Tue, Mar 21, 2017 at 2:37 PM, Adam Johnson  wrote:
>>>
 It does seem like a somewhat arbitrary historical restriction. Collin's
 PoC change is surprisingly small and simple.

 Seems like it would be fine if Django allowed add() and let any errors
> about missing data bubble-up.
>

>>> As the person who *made* the “somewhat arbitrary historical
>>> restriction”… :-)
>>>
>>> Honestly - the reason it was made was scope creep.
>>>
>>> I was trying to land Eric’s work on #6095, which was already moderately
>>> complex. Nobody disagreed that adding an object to an m2m with a through
>>> model was a *bad* idea - there were just a few design decisions that had to
>>> be made. But if we made those decisions, #6095 was going to take *another*
>>> couple of months to land; the perfect being the enemy of the good, we
>>> decided to limit scope and land “simple” m2m add, and revisit the issue
>>> later.
>>>
>>> I guess now is “later”… :-)
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/ms
>>> gid/django-developers/CAJxq849m632K%3DaMfXGBtF%3DhMXFS9ujzU6
>>> xfUzNxSRkkN_UrkqQ%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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/a32cf6ae-324a-40c1-b9d9-
> 31bd43af2c2c%40googlegroups.com
> 
> 

drop support for MySQL 5.5 in Django 2.0?

[Tim Graham]

MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a 
particular database version in the Django release prior to the end-of-life 
date [0], so that would mean dropping support in Django 2.1 (released 
August 2018). We don't have MySQL 5.5 testing in our continuous integration 
servers and in local testing, I noticed some GIS test failures with MySQL 
5.5. Before investigating them, I thought I'd ask to see if there might be 
consensus to drop support for MySQL 5.5 in Django 2.0 instead of 2.1. I'd 
guess anyone using MySQL 5.5 users would stick with Django 1.11 LTS or 
older.

https://github.com/django/django/pull/8980 shows the cleanups for removal 
of MySQL 5.5 support. Also, MySQL 5.5 is the last usage among the built-in 
database backends for the supports_microsecond_precision database feature 
so there's a chance that could be removed also, though I found usage of it 
in django_pyodbc [1].

[0] https://code.djangoproject.com/wiki/SupportedDatabaseVersions -- though 
we've made some exceptions like dropping support earlier for Oracle 11, 
https://groups.google.com/forum/#!topic/django-developers/IawbBWzPXaA/discussion
[1] https://github.com/lionheart/django-pyodbc/issues/87

-- 
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/367b0ca0-1ec9-48b6-a513-4c66a30c491d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: Allow to process data-migrations after flush

[Adam Johnson]

I've always thought flush is a weird command because an empty database is
very normally useless, because of data migrations. The docs do even say:

If you would rather start from an empty database and re-run all migrations,
> you should drop and recreate the database and then run migrate instead.


You can achieve this with:

./manage.py dbshell <<< 'drop database foo; create database foo ;'
./manage.py migrate

I've wrapped this up in the big application I work on with a separate
management command that basically does:

assert settings.DEBUG
cursor.execute('drop database; create database...')
call_command('migrate')

I think this solves your problem better than any change to migrations.
Executing "just one migration out of order" is not generally possible
unless it's strictly a data migration.


On 26 August 2017 at 00:41, Alan Arellano  wrote:

> Currently it's somewhat difficult to process initial data after a flush.
> You will need to fake the database state...
>
> In my case I'm creating all tables of the project with the migration 0001
> and populating with initial data on migration 0002.
>
> After spending a time looking for solutions found that I could achieve the
> desired result with:
> python manage.py flush
> python manage.py migrate app 0001 --fake
> python manage.py migrate app 0002
> python manage.py migrate app --fake
>
> While this works might be confusing (and risky), since django is indeed
> providing data-migrations, makes sense that after flushing the database one
> could repopulate the database easily. Since making 'flush' not to delete
> the data-migrations data seems overly complicated or simply impossible in
> real-world, makes sense to be able to --force a particular migration
> without touching others.
>
> Hope to read your comments. Greetings!
>
> --
> 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/ms
> gid/django-developers/bcb956ac-54b8-22e4-544e-a65c84647bdb%4
> 0solucioneslibres.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM32wOdry-Ls%3DUYz7VLdLUZ8fCNv5ce%3DN%3Di7HcM7-i3JRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.