Re: Best way to update relationships on fetch
Re: Best way to update relationships on fetch
- Subject: Re: Best way to update relationships on fetch
- From: Ray Ackland <email@hidden>
- Date: Mon, 13 Oct 2003 10:29:49 +1300
Thanks for the replies. I am trying to decide which way to go. In
response to your replies -
Arturo: I had started off on this path. I'm still weak on the bindings
thing, so will look into that more.
Chuck: I have experienced first hand EOFs unwillingness to be fooled. I
have also considered having an external script (most likely based
directly in SQL) to update the tables prior to the report. Will be
influenced by the frequency of reporting / likelihood of groupings
changing.
John: I already have methods to calculate current age etc from DOB, but
the reason I'm wanting to have it as a relationship is so I can fetch
the records which are in a certain range - and this calculation
wouldn't be available until after they were fetched.
As I write this, I have a feeling that someone is about to tell me
there is a much easier way to do what I am wanting (and hope this is
the case) but here are my goals: I have a group of clients (well, the
database does) who have certain attributes (in the general sense) -
age, ethnicity, gender, geographical location etc.
I am designing a report page which lets the user choose two of these
attributes and it creates a table showing the breakdown according to
the chosen attributes. So far I have been able to do this with all the
attributes but age. I was wanting an age grouping relationship so age
could be implemented without having to treat it as a special case.
Note: I am just counting the records which match the criteria. There
may be an easier way than fetching and counting the resulting NSArray.
Would it be more efficient to fetch all client objects and do in-memory
manipulation? If I did this, would I be able to use custom methods (ie
ageNow) in a qualifier?
Thanks for your feedback,
Ray.
On Sunday, Oct 12, 2003, at 14:09 Pacific/Auckland, Arturo Pirez wrote:
My take, which may or may not suit your purposes.
You have two tables: People and AgeGroupings. Define AgeGroupings
like so
DATE GroupBeginDate
DATE GroupEndDate
other necessary columns.
Then create a fetch spec along the lines of
AgeGrouping.GroupBeginDate <= $DOB
AND
AgeGrouping.GroupEndDate >= $DOB.
Then in your People EO you can write a cover method like so
public NSArray relatedAgeGroups() {
NSDictionary bindings = new NSDictionary(this.valueForKey("DOB"),
"DOB");
return
EOUtilities.objectsWithFetchSpecificationAndBindings(this.editingContex
t(),
"AgeGroupings",
"relatedAgeGroupingsFetchSpec",
bindings);
}
Well, that's my spin on it. Although one of the lists participants
will tell you that I overindulge
in model fetch specifications. :-)
On Sunday, Oct 12, 2003, at 14:57 Pacific/Auckland, Chuck Hill wrote:
I'd find some other way to achieve your goal. Perhaps Arturo's
suggestion
will work for you. What you are discussion below sounds a lot like
trifling with EOF. EOF does *not* enjoy being trifled with. :-)
Aging
could be handled with a nightly process that updated any people born
that
day. User definable age groups are probably best not implemented as
relationships.
Chuck
On Monday, Oct 13, 2003, at 01:46 Pacific/Auckland, John Boynton wrote:
Ray,
Do you need an age grouping table at all? Could you use a derived
attribute in your people entity that will calculate the age grouping
when the table is fetched?
John
_______________________________________________
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.