I had a use for such a feature, though I used an implementation more specific to my application. Basically, I have a model and then I have several other models that are directly related to that model. So in the base model I would have a field to determine if the instance was marked as deleted. I don’t have this field in the sub-models, so I would pass in the related name of the base model to create a queryset of all instances of the submodels that should be marked as deleted. Actually, that’s not exactly what I was doing, but the concept is there. Saying that, I am only doing that on one field on one model in my project.
From: 'Robert Schindler' via Django developers (Contributions to Django itself) [mailto:django-developers@googlegroups.com] Sent: Wednesday, July 10, 2019 2:13 PM To: Django developers (Contributions to Django itself) Subject: Prefixing Q Objects Hi all, I've been redirected to the mailing list from the ticked I opened [0]. Therein, I proposed to add a new method to the Q object API for prefixing Q objects with a related field's name in order to be able to create reusable Q objects. I think the use case I pointed out might have been misunderstood. Such an API would allow writing a manager like this one, let's say for a Subscription model: class SubscriptionManager(Manager): def active_q(self): return Q(cancelled=False) & Q(end_date__lt=datetime.datetime.now()) # This one is just for convenience and compatibility with the evolved practice def active(self): return self.filter(self.active_q()) We could then perform the following lookups: # All active subscriptions, nothing special here Subscription.objects.active() # Given that a user has a ManyToManyField subscriptions, get all users with active subscriptions, without repeating any business logic User.objects.filter(Subscription.objects.active_q().prefix("subscriptions")) The traditional approach would be to implement methods for filtering the queryset on both the managers for Subscription and User and thus duplicating logic, or use sub-queries like so: User.objects.filter(subscriptions__in=Subscription.objects.active()) which is clearly not wanted because of performance. What are your opinions? Best regards Robert [0] https://code.djangoproject.com/ticket/30631 -- 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<mailto:django-developers+unsubscr...@googlegroups.com>. To post to this group, send email to django-developers@googlegroups.com<mailto: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/30020900-7a4a-442e-9cce-af3d75a27c15%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/30020900-7a4a-442e-9cce-af3d75a27c15%40googlegroups.com?utm_medium=email&utm_source=footer>. 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/0c0a9f8a6dae49388bae789b926b9477%40iss2.ISS.LOCAL. For more options, visit https://groups.google.com/d/optout.
