Re: caching
Re: caching
- Subject: Re: caching
- From: Mike Schrag <email@hidden>
- Date: Wed, 11 May 2005 13:58:55 -0400
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:
This email sent to email@hidden
| References: | |
| | >caching (From: Mike Schrag <email@hidden>) |
| | >Re: caching (From: Sacha Mallais <email@hidden>) |