Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

[Ben Cole]

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.

Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

[Ben Cole]

This is what I wanted to know. I am willing to take on starting this DEP, 
with the caveat I've not done one before, and it will almost certainly 
require many revisions.

On Tuesday, 8 November 2016 15:32:48 UTC, Marc Tamlyn wrote:
>
> I have fed a lot into this discussion in person and on Slack. I don't 
> understand all the ins and outs completely, but I feel that the situation 
> is sufficiently complex enough that we need to consider it all together. 
> The code was certainly very challenging when I tried to make a UUID field 
> use a DB generated value and "return properly" when used as a pk, hence the 
> substandard docs for it. I'm personally -0 on the readonly patch unless it 
> does fit into a genuine coherent design.
>
> I personally believe we do need a DEP, and it needs to have the following 
> attributes:
> - Discussion of all the problems - refresh, read only, database level 
> defaults, primary keys and the auto generated "id" field.
> - Clear reference to all previous attempts to solve part(s) of the problem
> - A clear plan as to how all the use cases will be solved by the proposed 
> design
> - A road map of how to build the pieces one ticket at a time. readonly may 
> fit into this, it may not, that depends on the plan.
>
> This will allow everyone, but especially the technical board, to 
> understand all the considerations.
>
> Hope that helps. I may be overcomplicating the problem, but I don't think 
> I am.
> Marc
>
> On 8 November 2016 at 13:59, Joachim Jablon  > wrote:
>
>> We were having a discussion on this matter on the Django under the Hood 
>> Slack channel, and there's a design decision that I think I can't take by 
>> myself.
>>
>> There are 2 related subject : the "readonly" part and the "auto_refresh" 
>> part. Readonly means that the database won't try to write, autorefresh 
>> means that when creating /updating an instance, the value will be fetched 
>> from the database automatically
>>
>> There was a debate on whether the readonly behaviour should imply 
>> auto_refresh, and there are cases that are good candidates for auto_refresh 
>> without readonly (autofields, serial fields etc.).
>>
>> What I'd suggest, if we can get an agreement on this, would be to define 
>> those 2 behaviours completely independently (possibly as 2 different PRs, 
>> each with their tests and docs and such).
>>
>> Auto_refresh could then be used for autofields with the quirk that some 
>> SQL DBs, will provide last_insert_rowid() (sqlite) or LAST_INSERT_ID() 
>> (mysql), while other use RETURNING (PGSQL / Oracle) allowing to use a 
>> single query.
>>
>> Readonly, on its side, would only be a simple independent feature and its 
>> behaviour would do what the title says, no more, no less.
>>
>> Do you think I need to do a DEP on this ?
>> If not, do you think it's ok if 
>> https://github.com/django/django/pull/7515 is changed to only do the 
>> readonly part, and we make another PR (and possibly ticket) for the 
>> "auto_refresh" part ?
>>
>> While it would be nice to have both landing at the same time on master, I 
>> feel there's nothing blocking if they land at separate time, even in 
>> separate versions if need be (the freeze on Django 1.11 is coming fast, 
>> IIRC).
>>
>> Are there usecases that I'm missing and that could not be expressed as a 
>> mix of readonly and auto_refresh ?
>>
>> Le lundi 7 novembre 2016 15:35:38 UTC+1, Aymeric Augustin a écrit :
>>>
>>> On 7 Nov 2016, at 13:44, Joachim Jablon  wrote: 
>>>
>>> > My own personal opinion: 1. refesh by default, add an argument to 
>>> "model_instance.save()" to opt-out. 2. readonly 
>>>
>>> I agree. 
>>>
>>> -- 
>>> Aymeric. 
>>>
>>> -- 
>> 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/msgid/django-developers/3db52e5b-54db-4736-845b-58a22b6f015c%40googlegroups.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/85b9