Re: loading many objects from one query

[prev] [thread] [next] [Date index for 2004/09/14]

Wondering...

Why not go ahead and start thinking about the possibility of officially 
changing the status of the object index to object cache? Though the purpose 
of the index may be to prevent duplicate objects in memory, this does 
currently have the side effect of acting as a cache in some cases. It seems 
as though most people are thinking of the index in terms of a cache already, 
anyway. If I understand it correctly (which I'm not sure I do) the only 
difference would be that the object wouldn't be blown away in the 
index/cache when all other references to it go out of scope. (Perhaps the 
weakref functionality could be retained, but made optional.)

With a few fairly straightforward changes to CDBI to make the index/cache 
the first stop on the way to the DB in *all* cases where an id-based lookup 
is performed (this could include has_many and might_have), CDBI might pick 
up a lot of extra utility. (Caching wishes aside, it might be a win if only 
because things like retrieve() and has_a would be performing their lookups 
in a consistent manner.)

Todd Lorenz

>Tim Bunce wrote:
>>>The tricky part would be making the relationship accessors use an 
>>>in-memory cache instead of the database.  I would suggest doing that part 
>>>by writing your own relationship type that looks at a cache first and 
>>>then calls the normal has_many relationship code if it doesn't find 
>>>anything.
>>
>>
>>Umm. Seems like a bug/limitation of the caching code that construct() 
>>isn't
>>integrated with it in some way. Currently all uses of sth_to_objects()
>>don't consider the cache at all.
>
>That's because there is no cache. :)
>
>The existing object index is only intended to avoid having duplicates of 
>the same object in memory.  Caching relationships and avoiding database 
>hits is outside of that.
>
>- Perrin