Geee.... open your mouth one time and next thing you know, you've
volunteered for something :)
The code is fairly integrated into our design, so it won't be
meanignful for me to post it. I will try to clean it up so that it is
standalone, and post a wiki entry.
As for Gili's question, this method really does not allow you to "lazy
load" the objects. I'd be inclined to think that the performance gains
you might expect from lazy loading are fictitious. However, I have no
desire to hear you tell me why not, so I won't go down that road :)
I'll just say, if you want to lazy load, you should probably look at
writing your own manager to access your named queries. You can pass in
a DataContext and pull out the named query. The Context can then
decide whether or not to set refresh=true on a "one time only" basis,
based on the monitor that I will provide to the wiki when I get a
chance.
Cris
On 9/14/05, Gentry, Michael (Contractor) <michael_gentr..anniemae.com> wrote:
> *sniff* *sniff*
>
> Smells like a new wiki page? :-)
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Gili [mailto:cowwo..bs.darktech.org]
> Sent: Wednesday, September 14, 2005 9:51 AM
> To: cayenne-use..bjectstyle.org
> Subject: Re: Clearing query cache on commit
>
>
>
> Yes... I'm also quite interested. It sounds exactly like what
> I'm
> looking for, minus having to invoking the query right away with
> refresh=true. For performance reasons, I'd want to fault the query
> results right away but not actually invoke it. Is this possible?
>
> Gili
>
> Eric Schneider wrote:
> > Cris,
> >
> > This sounds very cool. Would you mind sharing your implementation?
> >
> > Thanks,
> > Eric
> >
> >
> > On Sep 14, 2005, at 9:04 AM, Cris Daniluk wrote:
> >
> >> I just have a process that iterates cached queries and looks to see
> if
> >> the class type matches the class type of any just-committed objects.
> >> If so, I re-execute those queries with caching disabled
> >> (refresh=true).
> >>
> >> Actually, I do it in a slightly different way that avoids unnecessary
> >> refetching, etc, but that's what you get for free. As currently
> >> running, it never unnecessarily tosses a cached query, and never
> >> misses a query that needs tossing.
> >>
> >> On 9/13/05, Gili <cowwo..bs.darktech.org> wrote:
> >>
> >>>
> >>> I did some more research and it seems that depending on the
>
> >>> cache type
> >>> (local or shared) the cached results are either stored in
> >>> DataRowCache.snapshotLists (for shared) or
> ObjectStore.queryResultMap
> >>> (for local).
> >>>
> >>> As far as I can tell, currently it is impossible to flush
> >>> these caches
> >>> safely (DRC.clear() always flushes another unrelated map). I'm
> looking
> >>> for a single method that will flush both the local and shared query
> >>> result caches.
> >>>
> >>> Gili
> >>>
> >>> Gili wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I need to clear the query cache on DataContext.commitChanges
> ().
> >>>> The
> >>>> only way I can see this working is if I invoke DataRowStore.clear
> ()
> >>>> but
> >>>> as Mike mentioned to me offline this sounds like an overly
> aggressive
> >>>> approach.
> >>>>
> >>>> Is there a finer-grained method for clearing query cache for
> all
> >>>> queries?
> >>>>
> >>>> My use-case is:
> >>>>
> >>>> 1) Database is empty
> >>>> 2) ContentType.getCanonicalInstance() returns an empty set, so I
> >>>> commit
> >>>> a new object to the database
> >>>> 3) DataContext.commitChanges()
> >>>> 4) I invoke ContentType.getCanonicalInstance() again. This time it
> I
> >>>> expect it to return the instance I commited to the DB in step 3,
> >>>> but it
> >>>> returns the cached result (empty set).
> >>>> 5) DataContext.commitChanges()
> >>>> 6) Database complains of unique constraint violation
> >>>>
> >>>> Currently I invoke
> >>>> "context.invalidateObjects(context.getObjectStore().getObjects ())"
>
> >>>> after
> >>>> each commitChanges(). I'd want to do something equivilent for the
> >>>> query
> >>>> cache.
> >>>>
> >>>> Thanks,
> >>>> Gili
> >>>>
> >>>
> >>> --
> >>> http://www.desktopbeautifier.com/
> >>>
> >>
> >
> >
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Wed Sep 14 2005 - 10:08:07 EDT