Re: PR review request

Hi William, 3.2 alpha marked the feature freeze. Only non-release blocking bug fixes may be backported at this point (from https://code.djangoproject.com/wiki/Version3.2Roadmap#schedule). There are 28 other patches in the review queue, many of which have been there longer than your tickets, so

PR review request

Django committers, The docs recommend posting here if a pull request hasn't seen any action in awhile—I'm sorry if this nudge is premature! There are a couple of PRs I'd love to get merged into 3.2 before the

GSoC proposal review request

Hi everyone! My name is Chetan Khanna. I'm one of the applicants for GSOC this summer. I had written a proposal for the GraphQL topic and posted it to the forum a week back. But with all the virus situation everywhere, couldn't really get it reviewed property. So I had a request for the communi

Re: PR review request https://github.com/django/django/pull/11157

Posting review request is not a part of our workflow. You should uncheck "Patch needs improvement" flag on the ticket if you think that it is ready for review. Currently it is not in tickets waiting for review (see Patches needing review <https://code.djangoproject.com/query?s

PR review request https://github.com/django/django/pull/11157

Not sure if posting review requests to mailing list is part of the process, but could we get https://github.com/django/django/pull/11157 reviewed/merged? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

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 DB

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, autorefre

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 "Django developers (Contri

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 fetch

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 to

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 change

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 t

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 mess

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 model._meta.new_style_deferr

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 Mod

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 deferred

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 t

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 sa

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 post-s

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 agree on: > > - controlli

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 the awkward “ignore w

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: > > MyModel.objects.defer(‘ignored_1’,

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 i

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 s

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 bac

[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 O

Re: review request for anyone who likes regular expression (increasing URLs accepted by URLValidator)

Thanks Tim for bringing that up :) The previous URLValidator would consider some valid URLs as invalid. That can cause a lot of problems, most people would expect an URL Validator to return some false negatives sometimes (invalid URLs considered valid) but not false positives (valid URLs considere

review request for anyone who likes regular expression (increasing URLs accepted by URLValidator)

Danilo Bargen has done some work to expand the types of URLs accepted by URLValidator. His patch adds support for IPv6 addresses, unicode domains, and URLs containing authentication data. This has increased the complexity of the regular expression quite a bit and I would appreciate if any expert

Re: [5-for-1] Review request

Hello, I would like a core dev's opinion on #11555. The tickets I reviewed are listed here: http://myks.org/stuff/django_5-for-1.txt Thanks, -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, se

Re: [5-for-1] Review request

On 04/25/2011 05:33 PM, Jacob Kaplan-Moss wrote: On Mon, Apr 25, 2011 at 10:28 AM, Jonas H. wrote: I'd like you to look into http://code.djangoproject.com/ticket/15696. Done. Unfortunately, the result's probably not what you wanted. If you'd like to re-use your review wuffie I'd happily take

Re: [5-for-1] Review request

On Mon, Apr 25, 2011 at 10:28 AM, Jonas H. wrote: > I'd like you to look into http://code.djangoproject.com/ticket/15696. Done. Unfortunately, the result's probably not what you wanted. If you'd like to re-use your review wuffie I'd happily take a look at something else instead; just let me know.

[5-for-1] Review request

Here's what I reviewed: http://code.djangoproject.com/ticket/15783 http://code.djangoproject.com/ticket/15774 http://code.djangoproject.com/ticket/15801 http://code.djangoproject.com/ticket/15896 http://code.djangoproject.com/ticket/15895 I'd like you to look into http://code.djangoproject.com/t

Re: Review request

On Sun, Apr 24, 2011 at 6:15 PM, Mathieu Agopian wrote: > My turn! > > I have reviewed #15885, #15886 (then closed as duplicate), #15887, > #15891, and #15889. > > The latter, #15889 is my first code+patch+doc contribution, and i'd > like it to be reviewed please. > > Thanks! > > Mathieu > > On Ap

Re: Review request: 15064, DJANGO_SETTINGS_MODULE environment variable ignored in runserver.

Thanks for the info and feedback on the patches today. I'll stop spamming the list. Shawn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this gro

Re: Review request: 15064, DJANGO_SETTINGS_MODULE environment variable ignored in runserver.

Hi Shawn -- FYI, we get updates to tickets sent over email (see the django-updates group) so you don't need to ping here when you've updated something -- we'll see it either way :) Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Review request

My turn! I have reviewed #15885, #15886 (then closed as duplicate), #15887, #15891, and #15889. The latter, #15889 is my first code+patch+doc contribution, and i'd like it to be reviewed please. Thanks! Mathieu On Apr 22, 2:13 pm, Jacob Kaplan-Moss wrote: > On Fri, Apr 22, 2011 at 3:26 AM, Ay

Review request: 15064, DJANGO_SETTINGS_MODULE environment variable ignored in runserver.

Patch with tests attached to ticket. http://code.djangoproject.com/ticket/15064 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send e

Re: [5-for-1] Review request

I noticed the "TODO" on the bottom of that page you linked... if you actually want to write something up for the docs about reviewing tickets (based on the discussion that's happened on the list the last few days) I'd suggest adding it to the /docs/howto/contribute section. Feel free to ping me

Re: [5-for-1] Review request

On Fri, Apr 22, 2011 at 3:26 AM, Aymeric Augustin wrote: > I have retroactively added 5 tickets for Alex's review, plus 5 tickets that > I'd like to trade against a review of #15255, especially the second comment. Done! BTW, I'm pretty sure Alex was joking about you needing to do five more, so d

Re: [5-for-1] Review request

2011/4/21 Alex Gaynor > As did I, do we have to retroactively require more reviews ;) > I'm now tracking my 5-for-1 deals here: http://myks.org/stuff/django_5-for-1.txt I have retroactively added 5 tickets for Alex's review, plus 5 tickets that I'd like to trade against a review of #15255, espe

Re: [5-for-1] Review request

On Thu, Apr 21, 2011 at 11:46 AM, Jacob Kaplan-Moss wrote: > On Thu, Apr 21, 2011 at 8:05 AM, Aymeric Augustin > wrote: > > I reviewed 5 new tickets: #15782, #15792, #15793, #15795, #15798. I'd > like > > someone to take a look at #14091. > > Done - thank you! I left comments on the ticket. > > J

Re: [5-for-1] Review request

On Thu, Apr 21, 2011 at 8:05 AM, Aymeric Augustin wrote: > I reviewed 5 new tickets: #15782, #15792, #15793, #15795, #15798. I'd like > someone to take a look at #14091. Done - thank you! I left comments on the ticket. Jacob -- You received this message because you are subscribed to the Google

[5-for-1] Review request

Hello, I suggest we gather review requests on this thread to make the core devs' job easier (that is, until the thread becomes too long). I reviewed 5 new tickets: #15782, #15792, #15793, #15795, #15798. I'd like someone to take a look at #14091. Best regards, -- Aymeric Augustin. -- You rec