• 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: Opinions on fetching/filtering
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opinions on fetching/filtering


  • Subject: Re: Opinions on fetching/filtering
  • From: Ken Anderson <email@hidden>
  • Date: Fri, 13 Jan 2006 11:33:20 -0500

James,

From what you've said, I would probably cache the user's current portfolio in the session and use in-memory filtering to generate results. If you're using any kind of cross instance notification mechanism, you could always hook that up to the project cache. I'm making the assumption that these objects aren't too big - if they're more than a few hundred bytes, I might reconsider that position.

As usual, YMMV!

Ken

On Jan 13, 2006, at 11:21 AM, James Cicenia wrote:

Sure -

Sizing:

A typical user will mostly be in one portfolio. A portfolio can have hundreds of projects. Of course
a user can switch portfolios. This is all in the session. Of course we have a couple dozen companies
who use the application, so, there can be quite a lot of objects in memory, I think.


So say for arguments sake 200projects * 3 portfolios * 20 Customers = 12,000 project objects.

Frequency:
Well every time a user switches a page it is making a request.

Relative Size:
hmmm, say the current 200 projects would return 6 different breakdowns.
For instance... a project has a workFlowState and a corresponding lifeCycleState.
These are regular string attributes of the project object. So, I need to show a lot of:
wfs1 + wfs2 + wfs3 (worflowstates) or
lcs1 - wfs1


etc.

4) two to four normally

5) mySQL ?? Just figured the whole round tripping, jdbc handoff, etc., would be worse
than letting EOF do as much as possible in memory. Thus the origin of my question.


- James Cicenia




On Jan 13, 2006, at 9:59 AM, Ken Anderson wrote:

James,

In my opinion, the answer depends on a number of factors:

1.  The size of the total set of data you're managing
2.  The frequency of requests
3.  The size of the requests results relative to the total data set
4.  The number of queryable attributes you might filter on
5.  The performance of your database back end

Also, in general, if EOF CAN handle it, I usually let it, and make sure that I've bumped up faulting amounts so that I minimize round trips.

Can you give us more detail?

Ken


On Jan 13, 2006, at 10:49 AM, James Cicenia wrote:

Hi -

I am getting a lot of requests for all these queries/fetches. I was wondering
that since the original set of projects will always be faulted in based upon
the relationship of Portfolio -->> Project, I was wondering if it would be faster
to just filter the existing array or to create a new database fetch?




Also, are NSSet operations fast or slow? Could I just create sets (views) of
the objects and then just union/intersect/subtract these sets??




Any comments would be appreciated.

- James Cicenia
_______________________________________________
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
  • Follow-Ups:
    • Re: Opinions on fetching/filtering
      • From: Art Isbell <email@hidden>
References: 
 >Opinions on fetching/filtering (From: James Cicenia <email@hidden>)
 >Re: Opinions on fetching/filtering (From: Ken Anderson <email@hidden>)
 >Re: Opinions on fetching/filtering (From: James Cicenia <email@hidden>)

  • Prev by Date: Re: Opinions on fetching/filtering
  • Next by Date: Re: Tomcat 5.5.12 WAR Deployment Problem
  • Previous by thread: Re: Opinions on fetching/filtering
  • Next by thread: Re: Opinions on fetching/filtering
  • Index(es):
    • Date
    • Thread