• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EOF Caching / performance question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
References: 
 >EOF Caching / performance question (From: Guido Neitzer <email@hidden>)
 >Re: EOF Caching / performance question (From: Chuck Hill <email@hidden>)
 >Re: EOF Caching / performance question (From: Guido Neitzer <email@hidden>)

  • Prev by Date: Re: NSArray to NSData
  • Next by Date: Re: EOF Caching / performance question
  • Previous by thread: Re: EOF Caching / performance question
  • Next by thread: Re: EOF Caching / performance question
  • Index(es):
    • Date
    • Thread