Re: Ability to annotate instances with querysets: reconsidering 30653

Hi Chris, Without wanting to preclude discussion of this kind of functionality ending up in Django itself, which I think would be great - I created https://github.com/alexhill/django-relativity to meet this kind of need. In your example, it would look a like this: from relativity import Relation

Re: FK field caching behavior change between 1.11.x and 2.x

I reckon stick with your first instinct SImon. I don't think using copy.copy needs to be an explicitly documented pattern. It's a heavily-used part of the standard library, and the objects Django provides should work with it as well as they can. The behaviour is surprising and buggy at face value:

Re: Proposal to format Django using black

Hi all, Could we do the work to make black (or another suitable formatter) apply only to a range of lines? Prettier has this feature[0], which is used by precise-commits[1] in the way we'd want to use it for Django. It takes a range of lines, expands the range to statement boundaries, and formats

Re: Proposal: relationships based on arbitrary predicates

Hi Silvio, Thanks for your feedback. David Sanders brought up something similar to ComputedField on GitHub[0] - a ForwardedField which can traverse relationships and present a field from a remote instance as if it were a local field. As long as it can traverse relationships, that use case would be

Re: Proposal: relationships based on arbitrary predicates

Hi Simon, Thanks for looking at this and for providing some context - I had looked at FilteredRelation but I hadn't seen reverse-unique. It makes me more confident that this is a good direction to take. I've reimplemented ReverseUnique using Relationship [0] and the tests pass, with the only code

Proposal: relationships based on arbitrary predicates

Hi all, I've run into many situations during my time using Django where I've wanted to be able to express relations based on some other criteria than foreign key equality. A few examples: - descendants or children of a node in a tree structure - saved search terms to search results - a model conta

Re: Automatic prefetching in querysets

I think this is an excellent suggestion. It seems generally accepted in this thread that although there are cases where this would hurt performance, it would on average solve more problems than it creates. The debate seems to be more whether or not it's "right" for the ORM to behave in this magica

Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

Here's a little bit more historical discussion on the topic: *https://groups.google.com/d/topic/django-developers/uWe31AjzZX0/discussion * On Wed, 22 Mar 2017 at 05:57 Russell Keith-Magee wrote: > On Tue, Mar 21, 2017 at

Re: Minor concerns about auth.models.User default settings

Hi David, Some background reading about the field length: https://groups.google.com/d/topic/django-developers/v3wYKWWYFT4/discussion https://code.djangoproject.com/ticket/20846 This contains some discussion as well: https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/discussion = And

Re: AbstractBaseUser.set_unusable_password() why a random string instead of an empty string?

Hi Jon, Here's the ticket where this was proposed: https://code.djangoproject.com/ticket/20079 And the commit that implements it: https://github.com/django/django/commit/aeb1389442d0f9669edf6660b747fd10693b63a7 Cheers, Alex On Thu, 20 Oct 2016 at 08:20 Jon Dufresne wrote: When set_unusable_p

Re: Add an argument to ModelChoiceField for callable function to set label for instance.

I like this! Having read through the existing ticket and discussion, really the only reason given is a cultural one: that subclassing is the way this kind of behaviour "should" be achieved. I disagree – IME, APIs that encourage parametrising small chunks of behaviour are succinct and flexible, and

PEP 484 type hinting in Django

Hi all, I like the plan to include PEP 484 type hinting in Django, outlined in the PyCharm promotion blog post. [1] Has this proposal been fleshed out much? Is there any extra information available anywhere that I've missed? I think this will be great for Django, and I'd happily contribute to the

ModelSignals with abstract senders

Hi all, currently when a model signal receiver is registered with an abstract model as the sender, we allow it even though the receiver will never be called. It would be nice if the signal registry wasn't polluted by bogus entries that will never be used. A few options: a) Make passing an abstrac

Re: Lazy operations refactor regression with abstract models #25858

Hi Simon, Nope, you're not missing anything. I agree with reverting the fix in #25858 and going with approach #2 as outlined in your initial post. Sorry that wasn't clear - I meant to address my response to the thread as a whole, in light of that fix being found to cause another regression. Chee

Re: Refactor year, month, day lookups?

In the dicts produced by a values query like that, what key would the result be found under? The full lookup string i.e. 'pub_date__month'? On Thu, Mar 26, 2015 at 2:36 AM, Anssi Kääriäinen wrote: > There remains a bit of work to do to make transforms usable everywhere in > the ORM. The example

Re: Adding an option on db_index to not create text/varchar_pattern_ops

Hi Marc, Great, that's very interesting reading! A lot of similarities to what I had in mind and a couple of differences. As I imagine the API, Indexes would be backend-specific rather than generic. Field would have a get_db_indexes() method which took a connection as its first argument like get_

Abstract models and the app registry

Hi all, I'm looking for some background about abstract models, specifically why they aren't registered with the app registry as normal models are. For some context, I'm working on a ticket [0] to refactor Django's lazy model operations (used e.g. to resolve string references in related fields). T

Displaying (some) M2M fields with through models specified

Hi all, Currently, only M2M fields without custom intermediary models can use the normal Django M2M form machinery. If you define your own intermediary models, you need to use inlines instead. I would like to allow fields with custom through models to use the regular M2M field/widget automaticall