Re: caching
Re: caching
- Subject: Re: caching
- From: Ken Anderson <email@hidden>
- Date: Wed, 11 May 2005 15:55:05 -0400
What I usually do in this situation is implement a static method that
will return the desired object. The class method is using either a
centralized editing context or its own, and caches all the EOs,
creating a dictionary on the implied primary key.
When you need the EO for a key, you call the static method with the key
and the editing context you want it in (or you could return the object
and clone it into your EC afterwards). It will look up the object in
the dictionary and hand it back in the desired EC.
Of course...this only works well for static data....
Ken
On May 11, 2005, at 1:58 PM, Mike Schrag wrote:
So the problem is that these are top level objects, so there's no
relationship I can traverse to get to them, which means that while the
row itself may come from the snapshot, a query is still executed to
retrieve the ID. And on any given page, I have to resolve as many as
40 of these by their Name field (for several technical reasons, the
EO's have to be looked up by name and can't exist as relationships
from the container EO). So every page kicking off 40 queries,
regardless of whether they pull the data or not, is pretty painful.
On May 11, 2005, at 1:37 PM, Sacha Mallais wrote:
On May 11, 2005, at 10:22 am, Mike Schrag wrote:
So I have a case where one of my EO's has a unique key which can't
be the primary key (it's changeable), but it is effectively the
primary key (that is, the EO is almost always looked up by that
key). I end up very frequently doing a qualifier on that field.
What is the recommended way to avoid hitting the database constantly
for these things? I would love to turn on Cache in Memory, but we
saw where that led me on the last situation (Incidentally, i tried
it again on this EO and it fails in the same way, which is to say,
it does nothing :) ). So what I really want here is a
most-recently-used cache mapped by the unique key. However,
properly implementing this without stepping on EOF's toes appears
that it might be really tricky (these EO's get updated and are
referenced by and from other EO's). Any suggestions or anyone run
into a similar problem?
Sounds like you should just be using the standard EOF caching. EOF
keeps a copy of your object's data in a cache called the snapshot.
If you _fetch_ data (via an EOFetchSpecification), EOF will go to the
database, but if you fire a fault (by traversing a relationship, for
example), EOF will only go to the database if the data does not
already exist in the snapshot.
HTH,
sacha
--
Sacha Michel Mallais - 400 lb. chimp
Global Village Consulting Inc.: http://www.global-village.net/
Choke on that, causality! -- the Professor, "Futurama"
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >caching (From: Mike Schrag <email@hidden>) |
| | >Re: caching (From: Sacha Mallais <email@hidden>) |
| | >Re: caching (From: Mike Schrag <email@hidden>) |