Re: EOF Caching / performance question
Re: EOF Caching / performance question
- Subject: Re: EOF Caching / performance question
- From: Chuck Hill <email@hidden>
- Date: Wed, 8 Mar 2006 09:43:38 -0800
HI Guido,
On Mar 8, 2006, at 8:33 AM, Guido Neitzer wrote:
On 08.03.2006, at 17:14 Uhr, Chuck Hill wrote:
No, they don't get cached. And the data is fetched again if you
try and turn them into EOs.
Okay. I see.
Assuming your page just fetches what it needs to display and does
not display a large amount of data, why use raw rows at all?
Because some of the EOs are not really "lightweight" and all that
is needed to display the page is one String attribute (the name for
the navigation item) and the id.
I have this situation: the complete side navigation is build
dynamically from a hierarchy of "Page" objects. Pages can have
subpages, the navigation can open a submenu for these cases. So, to
build the navigation arrays, I need to fetch about 30 to 40 page
objects from the database. These objects may have large text
content, images (via relationship, no problem with that) and a good
bunch of attributes (about 40).
Could you create a data structure (derived from the page objects) to
base this side navigation off of? This could just have the data (and
globalIDs if needed) and be stored at the session / application level.
So, raw rows aren't a good idea because they fetch all the stuff I
don't need AND they are not cached. So I can stick with raw sql to
fetch only the attributes I need to build the navigation or I can
go with EOs and hope for EOF caching (and have to look for ways to
refresh them for "preview" reasons, when something has changed in
the admin application).
Either a notification system, or fault them into an EC with a recent
fetch timestamp (say two minutes). Then any admin changes should
propagate within two minutes.
Why not just stick with EOs and take advantage of EOF's
caching? If the page is actually running fetch specs, as opposed
to just following relationships, consider caching the globalIDs
somewhere so change that DB access into fault firing. I'm not
sure if this is feasible in your case or not, but is worth
considering.
I currently switching an app from session based to direct actions
and I don't want to run into performance problems because of too
much db traffic.
Session-less makes this more challenging. You can't cache at the
session level so will need to do so at the app level and take care of
what happens when you update the cache, as would happen if you are
using a notification scheme.
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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