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/d34db1f8-db9e-45ef-a383-3573986677b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to