Fixed #28586 -- Added model field fetching modes. #17554

adamchainz · 2023-11-29T23:25:32Z

Trac ticket number

Branch description

Add QuerySet.fetch_mode() to set the fetch mode, controlling how on-demand field loading occurs. Include three fetch modes, FETCH_ONE (default, existing behaviour), FETCH_PEERS, and RAISE.

Checklist

This PR targets the main branch.
The commit message is written in past tense, mentions the ticket number, and ends with a period.
I have checked the "Has patch" ticket flag in the Trac system.
I have added or updated relevant tests.
I have added or updated relevant docs, including release notes if applicable.
I have attached screenshots in both light and dark modes for any UI changes.

adamchainz · 2024-03-26T22:53:26Z

@charettes I’ve been slowly but steadily chipping away at this. Would you like to make an initial review, particularly of the public API in the release notes, and the way that the callable interface works?

charettes · 2024-03-26T22:57:31Z

@adamchainz sure! Can it wait this weekend? I'm taking a long break for Easter so I should have plenty of focus time.

adamchainz · 2024-03-27T06:30:02Z

Of course, take your time.

charettes

👋 @adamchainz I just want to start by saying thank you for the continued work here, this is really looking promising 🙇

I discussed an idea on how defining a form of fetching protocol (like how resolvable w/ resolve_expression and compilable w/ as_sql work) to avoid unnecessary closures and keep fetcher modes to the strict minimum which is to receive an instance, a fetcher, and route the call to the fetcher.

There also seems to be a missing usage of fetch mode in ReverseOneToOneDescriptor.__get__ but maybe this is expected for now as this is still a WIP.

Lastly I left some comments with regards to naming. I'm sure others will have opinions as well but it felt like django.db.models.fetching and fetching_mode vs lazy might be a better .

charettes · 2024-04-08T02:31:54Z

django/db/models/lazy.py

+    pass
+
+
+def RAISE(instance, field, fetch_for_instances, **kwargs):


Any thoughts about including a WARN as well? It seems like the only remaining feature that doesn't make django-seal obsolete.

I was thinking of that, but then maybe users would want “fetch peers” + warnings, or log messages directly rather than warnings. Maybe something we can instead document the pattern for? Like:

def warn_then_fetch_peers(...): logger.warning("fetching peers!") return FETCH_PEERS(...) set_default_lazy_mode(warn_then_fetch_peers)

I see, that makes sense to separate non-terminal surfacing of leaks from the actual fetching implementation. I wonder if there is anything that we could provide to avoid such boiler plate though.

django/db/models/fields/related_descriptors.py

django/db/models/query_utils.py

django/db/models/lazy.py

django/db/models/fields/related_descriptors.py

adamchainz

Thank you Simon, thoughtful as always. (P.S. just finished your Django Chat episode yesterday, nice one!). I’ve replied inline to your comments and will work on an update.

There also seems to be a missing usage of fetch mode in ReverseOneToOneDescriptor.__get__ but maybe this is expected for now as this is still a WIP.

Yes, this needs doing, as does GenericForeignKey.

django/db/models/fields/related_descriptors.py

django/db/models/lazy.py

adamchainz · 2024-04-23T09:24:29Z

django/db/models/lazy.py

+    pass
+
+
+def RAISE(instance, field, fetch_for_instances, **kwargs):


I was thinking of that, but then maybe users would want “fetch peers” + warnings, or log messages directly rather than warnings. Maybe something we can instead document the pattern for? Like:

def warn_then_fetch_peers(...): logger.warning("fetching peers!") return FETCH_PEERS(...) set_default_lazy_mode(warn_then_fetch_peers)

django/db/models/query_utils.py

adamchainz · 2024-04-25T16:48:44Z

Yes, this needs doing, as does GenericForeignKey.

I tried GenericForeignKey just now, but it’s complicated:

django/django/contrib/contenttypes/fields.py

Lines 234 to 267 in ec85524

    
           def __get__(self, instance, cls=None): 
        
               if instance is None: 
        
                   return self 
        
               # Don't use getattr(instance, self.ct_field) here because that might 
        
               # reload the same ContentType over and over (#5570). Instead, get the 
        
               # content type ID here, and later when the actual instance is needed, 
        
               # use ContentType.objects.get_for_id(), which has a global cache. 
        
               f = self.model._meta.get_field(self.ct_field) 
        
               ct_id = getattr(instance, f.attname, None) 
        
               pk_val = getattr(instance, self.fk_field) 
        
               rel_obj = self.get_cached_value(instance, default=None) 
        
               if rel_obj is None and self.is_cached(instance): 
        
                   return rel_obj 
        
               if rel_obj is not None: 
        
                   ct_match = ( 
        
                       ct_id == self.get_content_type(obj=rel_obj, using=instance._state.db).id 
        
                   ) 
        
                   pk_match = ct_match and rel_obj._meta.pk.to_python(pk_val) == rel_obj.pk 
        
                   if pk_match: 
        
                       return rel_obj 
        
                   else: 
        
                       rel_obj = None 
        
               if ct_id is not None: 
        
                   ct = self.get_content_type(id=ct_id, using=instance._state.db) 
        
                   try: 
        
                       rel_obj = ct.get_object_for_this_type( 
        
                           using=instance._state.db, pk=pk_val 
        
                       ) 
        
                   except ObjectDoesNotExist: 
        
                       pass 
        
               self.set_cached_value(instance, rel_obj) 
        
               return rel_obj

A fetch() function would need to perform all this validation per-instance. I think for ease of coding and review, we should tackle it in a follow-up PR as an optimization.

charettes · 2024-05-05T19:43:33Z

This is looking great @adamchainz thanks for pushing this through and sorry for my slow replies.

If you'd like I could give a shot at implementing the GenericForeignKey part in a separate branch that targets this one. Even if it doesn't land in the same PR it would be great to validate that our approach works properly and possibly dog-food the newly introduced GenericPrefetch.

charettes · 2024-05-06T03:20:05Z

Completely untested code but from eye balling the other fetch methods the following should work without too much issues?

diff --git a/django/contrib/contenttypes/fields.py b/django/contrib/contenttypes/fields.py
index 770f88265c..2b7597623b 100644
--- a/django/contrib/contenttypes/fields.py
+++ b/django/contrib/contenttypes/fields.py
@@ -255,16 +255,30 @@ def __get__(self, instance, cls=None):
                 return rel_obj
             else:
                 rel_obj = None
-        if ct_id is not None:
-            ct = self.get_content_type(id=ct_id, using=instance._state.db)
-            try:
-                rel_obj = ct.get_object_for_this_type(
-                    using=instance._state.db, pk=pk_val
-                )
-            except ObjectDoesNotExist:
-                pass
-        self.set_cached_value(instance, rel_obj)
-        return rel_obj
+
+        get_fetching_mode()(self, instance)
+        return self.get_cached_value(instance)
+
+    def fetch(self, instances):
+        f = self.model._meta.get_field(self.ct_field)
+        if len(instances) == 1:
+            ct_id = getattr(instance, f.attname, None)
+            pk_val = getattr(instance, self.fk_field)
+            instance = instances[0]
+            rel_obj = None
+            if ct_id is not None:
+                ct = self.get_content_type(id=ct_id, using=instance._state.db)
+                try:
+                    rel_obj = ct.get_object_for_this_type(
+                        using=instance._state.db, pk=pk_val
+                    )
+                except ObjectDoesNotExist:
+                    pass
+            self.set_cached_value(instance, rel_obj)
+        else:
+            prefetch_related_objects(
+                instances, f.name
+            )
+

django/db/models/fields/fetching.py

charettes · 2024-05-06T04:15:59Z

Gave a shot at it here adamchainz#4

django/db/models/fields/fetching.py

tolomea · 2024-06-04T12:16:03Z

Thanks Adam for working to push this thing to it's final form. I wonder when the 10 year anniversary of our first version is.

I've had a skim, I plan to look at the details a bit more.

I quite like the fetching modes mechanism and name.

I don't know if this has been covered somewhere but separate modes for deferred fields and FK(and friends) makes a lot of sense to me and is probably what I will look to do in my own code.
With the current API I guess it's possible by doing isinstance checks inside a custom mode.
But that's not very obvious or discoverable.

My rationale here is when you fetch an object from the DB, unless you do stuff to say otherwise all the primitive fields are fetched and none of the FK's.
Absence of an FK is the default it means no one explicitly asked for it.
Absence of a primitive field is unusual it means someone explicitly said don't load this.
So I would want a config that automatically fetches the FK's (in bulk) and errors on the primitive fields.

tolomea · 2024-06-04T14:16:09Z

Also further to the above the doco encourages overridding refresh_from_db which makes setting FETCH_PEERS for deferred fields in your project a third party library compatibility risk as they might done that, although it does feel unlikely.

I wonder if it could / should detect a custom refresh_from_db in FETCH_PEERS and... warn? fall back to FETCH_ONE?

Likewise with the other backward compatibility things.

FWIW I looked though old notes and it seems like the OG version was sometime around September 2016 (later than I remember) so this might still make it into core before the 10th anniversary.

adamchainz · 2025-02-21T11:47:17Z

Hello all! @pelme pushed me to continue working on this 👍 I have just pushed a new version with these changes:

Rebased onto main with updates to target Django 6.0.
Merged in the branch from @charettes for GenericForeignKey support, plus a tweak to use a separate GenericForeignKeyFetcher class so it works with the RAISE method. (We could also split a descriptor class from GenericForeignKey to achieve this, but I’m concerned about backwards-compatibility, despite it not being public API.)
Renamed things to cover “fetch modes” (not fetching) consistently.
Added a database topic guide on fetch modes.

I don't know if this has been covered somewhere but separate modes for deferred fields and FK(and friends) makes a lot of sense to me and is probably what I will look to do in my own code.
With the current API I guess it's possible by doing isinstance checks inside a custom mode.
But that's not very obvious or discoverable.

I think I‘d rather not split into two separate fetch modes/features. That would be harder to explain and maintain. I would rather just allow custom modes to do this, and document how to. But that would require covering lots of internal APIs right now, which is why I’ve held back on it.

FWIW I looked though old notes and it seems like the OG version was sometime around September 2016 (later than I remember) so this might still make it into core before the 10th anniversary.

🤞

Review would be appreciated. I’m going to try testing this branch against some real projects to check for edge cases.

pelme

Amazing work! This looks great! Me, @Majsvaffla, @nip3o and @saeldion have made this review together. We are very much looking forward having fetch modes in Django.

docs/topics/db/fetch-modes.txt

pelme · 2025-03-06T08:15:50Z

docs/releases/6.0.txt

+
+The on-demand fetching behavior of model fields is now configurable with
+:doc:`fetch modes </topics/db/fetch-modes>`. Django provides three fetch
+modes:


should we also in this first paragraph call out that the main motivation for fetch modes is to prevent N+1 queries/missing select_related/prefetch_related on foreignkeys/related fields? fetch modes does more than that (deferred fields) but I still think that would be helpful for people reading this the first time.

It is stated below but I find this an important point to get across very early 🙂

docs/topics/db/fetch-modes.txt

docs/topics/db/optimization.txt

docs/topics/db/fetch-modes.txt

tests/model_fields/test_fetch_mode.py

docs/topics/db/fetch-modes.txt

charettes

I left a few comments about the global state fetcher approach, __set_name__ manual calls, systematic creation of peers: list[weakref].

charettes · 2025-03-06T16:38:10Z

django/db/models/fields/__init__.py

-            setattr(cls, self.attname, self.descriptor_class(self))
+            descriptor = self.descriptor_class(self)
+            setattr(cls, self.attname, descriptor)
+            descriptor.__set_name__(cls, self.name)


Could we potentially avoid calling these magic methods directly? Why can't descriptors rely on self.field.name instead if they require it?

The aim here was to have the "fetcher protocol" include a consistent way to see the related field's name available, so the RAISE mode can rely on it.

Descriptors did not consistently point at fields. At least GenericForeignKey is, oddly, its own descriptor. Adding a recursive field attribute there felt wrong, but it seemed to make sense to call __set_name__ here because it's the same point that Python would do so if the descriptor were placed in the class definition.

In retrospect, it's probably less invasive and more sensible to make field consistently available, and fix GFK to have a separate descriptor class. I'll give that a try now.

Okay, I just pushed a fix. It required a new commit that splits a descriptor class from GenericForeignKey, which I also put into a new PR at #19381. Another minor hack it required is a new property in ReverseOneToOneDescriptor for field, with a docstring explaining the ducktyping.

django/db/models/fields/related_descriptors.py

django/db/models/query.py

django/db/models/fields/fetch_modes.py

adamchainz · 2025-03-31T12:07:16Z

I've brought it before but the fact the fetch mode is a global variable as opposed to attributed to QuerySet instances is likely going to make ergonomics quite weird when wanting to mix modes for distinct querysets or enable it only in some cases.

I have just pushed a new version that is implemented solely as a QuerySet method.

After working through it, I agree with you, @charettes, that this cuts with the grain of Django. While the global state is convenient, it could easily mess up some expectations in third-party apps.

I thought it would be nice to allow swapping the default fetch mode, but from some experience testing this PR, I’m not 100% sure it’s a great idea. On one project that I tested, using the RAISE fetch mode broke migrations because some migration RunSQL operations in Wagtail relied on the default FETCH_ONE-style behaviour. Opting in individual QuerySets, or models through a custom manager is the safer option, if a little more involved.

I will respond to the other review comments later today, and I also intend to work on some further changes:

Nesting: copy a model instance’s fetch mode to related objects fetched through the fetch mode
Nesting: copy a model instance’s fetch mode through its related managers
Update select_related() and prefetch_related() docs to refer to fetch modes

adamchainz · 2025-03-31T16:15:28Z

Re @tolomea

I don't know if this has been covered somewhere but separate modes for deferred fields and FK(and friends) makes a lot of sense to me and is probably what I will look to do in my own code.

I understand the rationale for splitting behaviour between FKs and deferred fields, but I think actually splitting them in the API would be too fine-grained. Fetching deferred fields in bulk is still useful, such as for model classes that defer some fields by default.

With the current API I guess it's possible by doing isinstance checks inside a custom mode. But that's not very obvious or discoverable.

Yes, this would be the way. We could document a public API around combining fetch modes like this, but maybe in a follow-up PR.

Also further to the above the doco encourages overridding refresh_from_db which makes setting FETCH_PEERS for deferred fields in your project a third party library compatibility risk as they might done that, although it does feel unlikely.

Thankfully, this risk is gone by adopting a QuerySet-based API. Instead, third-party libraries will need to opt into using a different fetch mode.

adamchainz · 2025-04-14T14:28:25Z

I've just pushed an update with a new commit that does the "nesting", copying the fetch mode to related objects to apply to a whole tree of objects unless explicitly replaced.

I'm still going to work a bit on the select_related and prefetch_related docs, but I think we're nearly there on the QuerySet-based design.

adamchainz · 2025-04-15T13:20:55Z

I just fixed the test failure. (I wrote behaviour instead of behavior, failing the spellcheck!)

docs/ref/models/querysets.txt

g-nie

Thanks @adamchainz this looks great! I left a small thought

django/db/models/query_utils.py

docs/topics/db/optimization.txt

docs/topics/db/queries.txt

co-authored-by: Andreas Pelme <andreas@pelme.se> co-authored-by: Simon Charette <charette.s@gmail.com> co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>

jacobtylerwalls · 2025-05-03T13:45:08Z

docs/topics/db/optimization.txt

+Using this fetch mode is easier than declaring fields to fetch with
+:meth:`~django.db.models.query.QuerySet.select_related` or
+:meth:`~django.db.models.query.QuerySet.prefetch_related`, especially when it's
+hard to predict which fields will be accessed.


I've been puzzled before why prefetch_related() does nothing, but select_related() selects everything. We could straighten this out if we let prefetch_related() resolve to fetch_mode(models.FETCH_PEERS), if I understand correctly?

that select_related() call is almost always a bad idea, it's very prone to over fetching and to doing so in a way that is fairly hostile to the database, I'd be more in favor of removing that behaviour

I lean towards removing that, too. It’s worth noting that the admin allows users to use it:

django/django/contrib/admin/views/main.py

Lines 601 to 602 in 7e4b371

if self.list_select_related is True:

return qs.select_related()

Maybe enough people rely on it that it’s not worth removing though...? Seems kinda handy for rapid prototyping at least.

Strong +1 to deprecating select_related() without a mask as a follow up that's almost always a bad idea.

docs/ref/models/querysets.txt

charettes

Thanks for pushing this forward and sorry for the delay in review @adamchainz.

I left a few comments mainly requesting clarifications and more verbose commit message but in essence the state of this PR is looking great to me 🥇 🙇

charettes · 2025-07-06T03:21:58Z

docs/topics/db/optimization.txt

+Using this fetch mode is easier than declaring fields to fetch with
+:meth:`~django.db.models.query.QuerySet.select_related` or
+:meth:`~django.db.models.query.QuerySet.prefetch_related`, especially when it's
+hard to predict which fields will be accessed.


Strong +1 to deprecating select_related() without a mask as a follow up that's almost always a bad idea.

charettes · 2025-07-08T01:37:18Z

django/contrib/contenttypes/fields.py

@@ -157,11 +156,19 @@ def get_content_type(self, obj=None, id=None, using=None, model=None):
            # This should never happen. I love comments like this, don't you?
            raise Exception("Impossible arguments to GFK.get_content_type!")

+
+class GenericForeignKeyDescriptor:


Just to make sure I understand the rationale behind this change.

The same thing could be achieved by adding a field property on GenericForeignKey that returns self but a distinct class is deemed preferable as it makes GenericForeignKey follow the pattern used by other related fields.

It might be worth explaining the rationale behind these changes in the commit message and the benefits it provides for the followed commits in the patch set for future reference.

charettes · 2025-07-08T01:42:13Z

docs/topics/db/queries.txt

-:class:`~django.db.models.ManyToManyField`), instances of that model will have
-a convenient API to access the related object(s).
+:class:`~django.db.models.ManyToManyField`), instances of the model class gain
+accessor attributes for the related object(s).


Again sensible chain but a commit description would go a long way explain why this is being done here for future reference.

charettes · 2025-07-08T01:44:59Z

django/contrib/contenttypes/fields.py

-        return rel_obj
+
+    def fetch_many(self, instances):
+        missing_instances = [i for i in instances if not self.field.is_cached(i)]


Minor but it might be worth using a local reference for self.field.is_cached to avoid two attribute lookups per instance in a potentially large loop

is_cached = self.field.is_cache missing_instances = [i for i in instances if not is_cached(i)]

charettes · 2025-07-08T01:48:55Z

django/db/models/base.py

+        state.pop("fetch_mode", None)
+        state.pop("peers", None)


Just to make sure I understand, does this mean that a pickled model instances, and by definition a queryset of such objects, looses its fetch mode affinity? For example would that mean that caching a queryset though pickling and then unpickling it would not preserve the specified mode (e.g. raising errors on attributes that would require fetching).

Maybe that's by design but the lack of comments makes me wonder the purpose behind it.

charettes · 2025-07-08T01:50:46Z

django/db/models/fetch_modes.py

+        raise FieldFetchBlocked(f"Fetching of {klass}.{field_name} blocked.")
+
+
+RAISE = Raise()


Really like how this turned out, thanks for the tweaks!

charettes · 2025-07-08T01:59:07Z

django/db/models/fields/related_descriptors.py

+    def get_queryset(self, *, instance):
+        return self.related.related_model._base_manager.db_manager(
+            hints={"instance": instance}


I appreciate that a clearer signature is used but it should be done in a distinct commit as it might be used under other circumstances in the wild.

charettes · 2025-07-08T02:00:07Z

django/db/models/fields/related_descriptors.py

+            querysets[0] if querysets else self.get_queryset(instance=instances[0])
+        )
        queryset._add_hints(instance=instances[0])


Aren't these two instance hint passing redundant?

jacobtylerwalls · 2025-08-07T21:44:57Z

django/db/models/fetch_modes.py

+    def fetch(self, fetcher, instance):
+        klass = instance.__class__.__qualname__
+        field_name = fetcher.field.name
+        raise FieldFetchBlocked(f"Fetching of {klass}.{field_name} blocked.")


Thanks for this tool, currently using it to debug a project. I noticed that with RAISE, the exception raised here will include context like:

Traceback (most recent call last): File "/Users/jwalls/django/django/db/models/fields/related_descriptors.py", line 231, in __get__ rel_obj = self.field.get_cached_value(instance) File "/Users/jwalls/django/django/db/models/fields/mixins.py", line 21, in get_cached_value return instance._state.fields_cache[self.cache_name] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^ KeyError: 'nodegroup' During handling of the above exception, another exception occurred:

What do you think about raising this error from None to suppress that irrelevant context?

blighj · 2025-08-08T07:40:24Z

docs/topics/db/fetch-modes.txt

+.. admonition:: Referencing fetch modes
+
+    Fetch modes are defined in ``django.db.models.fetch_modes``, but for
+    convenience they're imported into :mod:`django.db.models`. The standard
+    convention is to use ``from django.db import models`` and refer to the
+    fetch modes as ``models.<mode>``.


I like this admonition, but the examples in the docs or the tests with this PR don't use this pattern.
If we are going to encourage this models.<mode> pattern, I think it should be used in the examples and tests too.

adamchainz force-pushed the ticket_28586 branch from 6f35264 to 61af026 Compare February 13, 2024 23:20

adamchainz changed the title ~~Fixed #28586 -- Added model field lazy loading modes.~~ Fixed #28586 -- Added model field lazy-loading modes. Feb 13, 2024

adamchainz force-pushed the ticket_28586 branch from 5787d68 to 5708991 Compare February 15, 2024 22:18

adamchainz force-pushed the ticket_28586 branch from 5708991 to bc159cf Compare March 8, 2024 22:35

adamchainz force-pushed the ticket_28586 branch from bc159cf to 43cd3ec Compare March 18, 2024 22:59

adamchainz requested a review from charettes April 7, 2024 09:56

charettes reviewed Apr 8, 2024

View reviewed changes

adamchainz commented Apr 23, 2024

View reviewed changes

adamchainz force-pushed the ticket_28586 branch 2 times, most recently from ad1b6d0 to 19c4f6e Compare April 25, 2024 16:45

charettes reviewed May 6, 2024

View reviewed changes

django/db/models/fields/fetching.py Outdated Show resolved Hide resolved

charettes reviewed May 6, 2024

View reviewed changes

django/db/models/fields/fetching.py Outdated Show resolved Hide resolved

adamchainz force-pushed the ticket_28586 branch from 19c4f6e to 0420124 Compare February 20, 2025 17:38

adamchainz changed the title ~~Fixed #28586 -- Added model field lazy-loading modes.~~ Fixed #28586 -- Added model field fetching modes. Feb 20, 2025

adamchainz force-pushed the ticket_28586 branch 3 times, most recently from 66c48bd to def10a7 Compare February 21, 2025 11:40

adamchainz force-pushed the ticket_28586 branch 3 times, most recently from f509590 to e1fca06 Compare February 21, 2025 22:02

pelme reviewed Mar 6, 2025

View reviewed changes

charettes reviewed Mar 6, 2025

View reviewed changes

adamchainz force-pushed the ticket_28586 branch from b596f1d to c375047 Compare March 31, 2025 11:50

adamchainz force-pushed the ticket_28586 branch 3 times, most recently from 94db176 to 2a55dc4 Compare March 31, 2025 16:08

adamchainz force-pushed the ticket_28586 branch from 2a55dc4 to d138911 Compare April 14, 2025 14:24

adamchainz force-pushed the ticket_28586 branch 5 times, most recently from 61aa0fc to 548939e Compare April 15, 2025 13:15

Zerotask reviewed Apr 16, 2025

View reviewed changes

docs/ref/models/querysets.txt Outdated Show resolved Hide resolved

adamchainz force-pushed the ticket_28586 branch from 548939e to b676579 Compare April 17, 2025 09:25

g-nie reviewed Apr 27, 2025

View reviewed changes

django/db/models/query_utils.py Show resolved Hide resolved

jacobtylerwalls reviewed Apr 27, 2025

View reviewed changes

docs/topics/db/optimization.txt Outdated Show resolved Hide resolved

docs/topics/db/queries.txt Outdated Show resolved Hide resolved

adamchainz and others added 4 commits April 29, 2025 23:40

Refs #28586 -- Split descriptor from GenericForeignKey.

7a61735

Refs #28586 -- Edited related objects documentation.

2db60d7

Fixed #28586 -- Added model field fetch modes.

d378302

co-authored-by: Andreas Pelme <andreas@pelme.se> co-authored-by: Simon Charette <charette.s@gmail.com> co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>

Refs #28586 -- Copied fetching modes to related objects.

03a80bb

adamchainz force-pushed the ticket_28586 branch from b676579 to 03a80bb Compare April 29, 2025 22:41

jacobtylerwalls reviewed May 3, 2025

View reviewed changes

docs/ref/models/querysets.txt Show resolved Hide resolved

charettes reviewed Jul 8, 2025

View reviewed changes

jacobtylerwalls reviewed Aug 7, 2025

View reviewed changes

blighj reviewed Aug 8, 2025

View reviewed changes

		pass


		def RAISE(instance, field, fetch_for_instances, **kwargs):

	if self.list_select_related is True:
	return qs.select_related()

		raise FieldFetchBlocked(f"Fetching of {klass}.{field_name} blocked.")


		RAISE = Raise()

Uh oh!

Fixed #28586 -- Added model field fetching modes. #17554

Are you sure you want to change the base?

Fixed #28586 -- Added model field fetching modes. #17554

Uh oh!

Conversation

adamchainz commented Nov 29, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Trac ticket number

Branch description

Checklist

Uh oh!

adamchainz commented Mar 26, 2024

Uh oh!

charettes commented Mar 26, 2024

Uh oh!

adamchainz commented Mar 27, 2024

Uh oh!

charettes left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

adamchainz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

adamchainz commented Apr 25, 2024

Uh oh!

charettes commented May 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

charettes commented May 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

charettes commented May 6, 2024

Uh oh!

Uh oh!

tolomea commented Jun 4, 2024

Uh oh!

tolomea commented Jun 4, 2024

Uh oh!

adamchainz commented Feb 21, 2025

Uh oh!

pelme left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

charettes left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamchainz commented Nov 29, 2023 •

edited

Loading

charettes commented May 5, 2024 •

edited

Loading

charettes commented May 6, 2024 •

edited

Loading

adamchainz commented Mar 31, 2025 •

edited

Loading