So the PR followed here : https://github.com/django/django/pull/7515
The PR is based on the idea defined by Ben just above.
It raised 2 questions which I'd like to bring to your attention :
1. When inserting or updating a model instance that contains one or more
readonly fields, should we fetch the readonly fields values from the
database (instance.refresh_from_db(fields=readonly_fields))
Pro :
- Consistent with AutoFields
- Easier to work with
- Can be done without an extra query for PGSQL using RETURNING (but it's
out of scope for this ticket. That being said, it could be done within the
1.11 scope)
Con :
- Intruduces an extra select query for models that have at least 1 readonly
field.
- Can be easily done manually (especially if we provide a model instance
such as ".refresh_readonly_fields()")
Alternative choice :
Give the choice to the user (in this case we still need to choose the
default behaviour)
It's worth noting that the only affected models are those that include a
"readonly" field, so that's not an extra select for everyone but only for
the adopters of the new feature. It's also worth noting that the select is
affecting a single element, using its pk, and targetting only the readonly
fields.
2. For now this feature is named "readonly" and its default value is False.
There was a suggestion to rather user the word "writable" and have its
default value to True. I think both terms carry the same information.
Pro "readonly"
It's easier to name things in the code ("readonly fields" is a simpler
concept than "non-writable fields" or "unwritable fields")
Pro "writable"
I'm not sure, but there were 3 :+1: on the GitHub comment so it's probably
clearer
My own personal opinion: 1. refesh by default, add an argument to
"model_instance.save()" to opt-out. 2. readonly
Le samedi 5 novembre 2016 16:17:31 UTC+1, Ben Cole a écrit :
>
> As discussed with many core team members (Simon Charette, Josh Smeaton,
> Marc Tamlyn, Tim Graham) at DUTH 2016 sprints, myself and Joachim
> Jablon have proposed a new, simpler solution to this. See
> https://code.djangoproject.com/ticket/27446
>
> The proposal therefore is to add a `readonly` option to the base `Field`
>> class that when `True` would strip these fields from being compiled to SQL
>> during `INSERT`s and `UPDATE`s. This allows for a very simple change that
>> covers all possible write queries that Django may perform (including
>> bulk_*).
>> There exists a proof of concept
>> https://github.com/novafloss/django-readonly-field
>
>
> PR to follow soon...
>
> On Friday, 12 February 2016 12:32:11 UTC, Anssi Kääriäinen wrote:
>>
>> On Thursday, February 11, 2016 at 2:41:44 PM UTC+2, Florian Apolloner
>> wrote:
>>>
>>> Oh, I somewhat missread and though there would be a new DEFERRED
>>> argument, the backwards issue is easy enough though:
>>>
>>> * Unless I miss something, YourModel.__init__ is Model.__init__ if the
>>> user didn't change it -> pass is DEFERRED
>>> * If the user changed it check for model._meta.new_style_deferred and
>>> continue accordingly
>>> * Raise a warning if the __init__ is a custom one and
>>> new_style_deffered is not set…
>>>
>>
>> If we are going to introduce a backwards compat system for this, then I
>> think I want to get rid of calling Model.__init__ at all when loading from
>> DB. We get faster model initialization, and conceptually loading from DB is
>> like unpickling which (correctly) doesn't call __init__.
>>
>> However, based on the comments in the PR, I think we are going to just
>> document the change to __init__ and skip deprecation.
>>
>> - Anssi
>>
>>
>>>
>>> On Thursday, February 11, 2016 at 1:38:44 PM UTC+1, Florian Apolloner
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Thursday, February 11, 2016 at 10:51:59 AM UTC+1, Anssi Kääriäinen
>>>> wrote:
>>>>>
>>>>> Before doing any further work on this we should decide if the
>>>>> Model.__init__() problem is bad enough to stop this cleanup, and if so,
>>>>> do
>>>>> anybody have any ideas of how to avoid the problem?
>>>>>
>>>>
>>>> I do not think Model.__init__() is anywhere near public API, add it to
>>>> the release notes and be done with it, worst case add a try/except around
>>>> it…
>>>>
>>>> Cheers,
>>>> Florian
>>>>
>>>
--
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/2e8733b3-8336-4dad-909c-6a97711a9aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
