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

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.

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

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

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

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,

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

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

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

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

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

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

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

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

Re: [Review Request] Added support for database delegated fields (like AutoField)

Hi Anssi, On 02/11/2016 02:51 AM, Anssi Kääriäinen wrote: > I created a proof-of-concept pull request for improved deferred fields > loading. See https://github.com/django/django/pull/6118. In short, it is > faster and cleaner (no more dynamically created subclasses for deferred > loading!) than

Re: [Review Request] Added support for database delegated fields (like AutoField)

On Thursday, February 11, 2016 at 1:41:44 PM UTC+1, Florian Apolloner wrote: > > * Unless I miss something, YourModel.__init__ is Model.__init__ if the > user didn't change it -> pass is DEFERRED > Sadly this is not true, you can check if __init__ is in dict though… -- You received this

Re: [Review Request] Added support for database delegated fields (like AutoField)

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

Re: [Review Request] Added support for database delegated fields (like AutoField)

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

Re: [Review Request] Added support for database delegated fields (like AutoField)

On Wednesday, February 3, 2016 at 8:47:16 AM UTC+2, Anssi Kääriäinen wrote: > For the update_fields change, I think we can do that completely > separately. The same goes for changing the way how deferred fields are > implemented. > I created a proof-of-concept pull request for improved

Re: [Review Request] Added support for database delegated fields (like AutoField)

Like it has been discussed a while ago [1] about adding *db_default*, we should stick with something similar to that and support updates as well. My 2 cents here. I like the idea Anssi has proposed to delegate as much as possible using expressions. So I would propose similar to what discussed in

Re: [Review Request] Added support for database delegated fields (like AutoField)

Shai and Ayeric, thank you so much for the feedback. The PR did indeed snowball into a much bigger one that I had initially planned. I agree with all points except, > - controlling this behavior in the query rather than in the field definition — this avoids the awkward “ignore what the field

Re: [Review Request] Added support for database delegated fields (like AutoField)

The options for save() API seem to be: 1. refresh_fields=[...] for save() - if set, then issue RETURNING for fields mentioned in the refresh_fields API. 2. expressions: my_model.updated_at = TransactionNow(); my_model.save(), where TransactionNow is flagged to refresh the value from DB

Re: [Review Request] Added support for database delegated fields (like AutoField)

On Monday, February 1, 2016 at 10:33:26 AM UTC+2, Aymeric Augustin wrote: > > > On 31 janv. 2016, at 22:55, Shai Berger > wrote: > > > > Your message seems to be confusing the queryset API with the > model-instance > > API. > > Oops :-( > > Anyway, it seems that we

Re: [Review Request] Added support for database delegated fields (like AutoField)

> On 31 janv. 2016, at 22:55, Shai Berger wrote: > > Your message seems to be confusing the queryset API with the model-instance > API. Oops :-( Anyway, it seems that we agree on: - controlling this behavior in the query rather than in the field definition — this avoids

Re: [Review Request] Added support for database delegated fields (like AutoField)

Hi Aymeric, Your message seems to be confusing the queryset API with the model-instance API. Details below. On Sunday 31 January 2016 21:24:17 Aymeric Augustin wrote: > > 1) Ignore some fields on updates > > Django already provides three ways to do this: > >

Re: [Review Request] Added support for database delegated fields (like AutoField)

Hello Owais, I had flagged this for review but it didn’t make it to the top of my list until today, sorry. The current approach adds 7 new APIs that only target the use case exposed in the ticket, which I find rather narrow. Some of these APIs (ignore_delegated) only exist to work around the

Re: [Review Request] Added support for database delegated fields (like AutoField)

Tim, I assumed the explanation and discussion on the ticket would be enough. I'll write it up if I find some time next week. Thanks On Saturday, January 23, 2016 at 2:39:45 AM UTC+5:30, Tim Graham wrote: > > It would be helpful if you could sketch out the proposal a bit more -- > maybe write

Re: [Review Request] Added support for database delegated fields (like AutoField)

It would be helpful if you could sketch out the proposal a bit more -- maybe write some documentation that explains and motivates the feature (and put explanation in this thread). The pull request description has some explanation but it doesn't seem suited toward someone unfamiliar with the

[Review Request] Added support for database delegated fields (like AutoField)

Hi, I would really appreciate if someone could review the API design (and implementation) for a PR I created. The PR implements support for fields that are assigned a value by the database (using a default value or trigger) instead of Django. It also adds support for PostgreSQL’s RETURNING and