Re: EOF Caching / performance question
Re: EOF Caching / performance question
- Subject: Re: EOF Caching / performance question
- From: Ken Anderson <email@hidden>
- Date: Wed, 08 Mar 2006 11:44:31 -0500
Guido,
Again, you're talking about a very small number of rows - this should
not be a performance problem at all. Have you looked into any other
faults that might be firing?
If your EO's are REALLY huge and it does turn out that fetching all
that data is slow (maybe your DB connection is slow?) - you could
consider creating a Lite EO, which only has the attributes you need.
What I typically do for this type of situation is make a lite version
of the EO, have it access the same table as the main EO, but only
have the small number of attributes you need. Then, create a
relationship from the lite EO to the main EO so that you can access
the real one when you need it.
I would make the lite EO read only, and if you add a lot of the main
EOs to the database often, you'll have to make sure the lite eo's are
refetched when you need them, since they naturally won't just
'appear' when the main EO is saved.
Ken
On Mar 8, 2006, at 11: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).
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).
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.
cug
--
PharmaLine, Essen, GERMANY
Software and Database Development
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
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