FETCH_BY_ID is undocumented #43
Comments
|
That all sounds true. It tries to find objects by looking up their id in cache instead of pulling everything from the database. The tradeoff is an extra query for id. |
|
Ok, I'll submit a patch for this documentation bit in the next day or two. |
|
Awesome, thanks Tim! On Tue, Jul 23, 2013 at 11:07 AM, Tim Gross notifications@github.comwrote:
|
|
I haven't submitted that patch yet because when we started running tests with FETCH_BY_ID set to True, there is a definite semantic change with respect to how it treats multidb. This is probably because when I submitted patches for multidb I didn't account for the setting at the time, and I think that the multidb patch turns out to have some weird behavior in the case of master-slave replication. I'm working on some test cases that demonstrate the behavior fully and some suggested patches for multidb support that I think will get it right. I'm targeting the fix to our next sprint (starting after next week), so it might be a couple weeks before I have anything for you but it'll be reasonably well-tested at that point. |
@jbalogh, the FETCH_BY_ID setting doesn't appear in the documentation.
I'd be willing to submit a documentation patch if you wouldn't mind giving me a little steering on it. In a previous PR I wrote a test for it and it looks like FETCH_BY_ID is designed to get partially-iterated querysets out of cache first (using
multi_get) and then from the DB. This looks to me like it should reduce the number of required cache hits considerably. Does this sound accurate to you?The text was updated successfully, but these errors were encountered: