Re: Queries
Re: Queries
- Subject: Re: Queries
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 27 Jan 2004 11:42:32 -0600
It depends. It's up to you. Do you want to load a bunch of objects
into memory, and then filter them in memory into your subsets? Or do
you want to fetch each subset with a seperate trip to the db?
Either could be appropriate, depending on what you are doing, how
long each takes, what kind of performance you need, etc.
One thing to keep in mind is 'data freshness':
1) An array fetched from the database, it's contents won't ever
change, even if the data underlying it changes. Of course, you can
manually refresh it whenever you want.
2) Relationship contents generally _are_ automatically maintained
'fresh' in your app, at least as far as changes made by your app. If
some other part of code changes the contents of the relationship,
then, well, the contents of the relationship are changed for
everybody. Of course, if _another app_ (or another instance of the
same app) changes the contents of the db, the first app instance
isn't going to know about it---and getting the contents of a
relationship 'freshened' as to underlying db changes, it can be
pretty tricky, unfortunately. Of course, on top of this, if you are
deriving your own array _from_ a relationship, your own array won't
automatically change every time the relationsihp changes, you will
have to decide a strategy for 'freshening' your derived subset based
on the underlying relationship contents (which themselves may or may
not need to be 'freshened' with regards to the underlying db).
Anyway, hope I haven't confused you too much, but there's no magic
answer. There are several appropriate ways of doing what you need, in
my opinion. Depending on what seems easiest and/or most performance
efficient, in your given situation. The issue of 'freshness' is the
only key somewhat complex issue to consider.
--Jonathan
At 10:44 AM -0600 1/27/04, james cicenia wrote:
Ok -
I have been perusing the voluminous documentation and apis and I came
across EOQualifier. I was wondering if I should use this method to create
my many subsets of data after pulling my objects via the one to many
relationship. Originally, I was modeling all of this with EOModelers Fetch
Specifications but that would always go to the database first.
Would it be cleaner and more efficient to code all my sub-selects as methods
in the base classes that EOModeler creates for me using EOQualifier?
For instance my portfolio object will have many projects with
different status, etc. and these would be displayed in their own
particular pane on the web page.
Just fishing for good design patterns here.
Sincerely,
James Cicenia - President/CEO
cell: 773.398.4649
www.jimijon.com
~~~~~~
The Internet's only Weekly Video Horoscope!
http://absinthium.jimijon.com
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
| References: | |
| | >Queries (From: james cicenia <email@hidden>) |