On Aug 11, 2009, at 11:32 AM, Michael Halliday wrote:
Hi List,
Let's say you have in your model:
Customer -->> Transactions
Since a customer could have 1000's or 10000's transactions ...
obviously you wouldn't want to have transactions as a class property
on the Customer EO for performance reasons. Normally you would
never want to get at ALL the transactions for a customer at once,
but you might want to get "Open" transactions or "Flagged"
transactions. So, for example you could have a method on the
Customer EO that just fetches the Transaction with a qualifier as
below:
public NSArray<Transaction> openTransactions() {
return Transaction.fetchTransactions(editingContext(),
Transaction.CUSTOMER.eq(this).and(Transaction.STATUS.eq("Open")),
null);
}
I generally will have a private variable in the EO:
private NSArray<Transaction> openTransactions;
Then the above method would change to:
public NSArray<Transaction> openTransactions() {
if(openTransactions == null) {
openTransactions = Transaction.fetchTransactions(editingContext(),
Transaction.CUSTOMER.eq(this).and(Transaction.STATUS.eq("Open")), null);
}
return openTransactions;
}
Then you'll need to manually manage at what point you need to refresh
the data stored in the openTransactions variable. I usually would add
openTransactions = null to the methods that add-to or remove-from the
relationship. This is a bit heavy handed though. You may want to do
something more fine-grained if you start running into performance
issues.
Dave
Now, this is all well and good ... but what's the "best practice"
for caching this result? You wouldn't want to bind this method up
to a WORepetition for example! I'd just be curious to see how other
people are handling these situations. Do you cache this stuff in
the EO itself ... or do you just limit calls to such methods and
cache the return value? I'm basically describing the role of Core
Data's fetched properties.
Cheers,
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
