First issue I see is how you can know what transaction objects occur prior
to any given object. I don't think you can rely on objects being retrieved
in any specific order that your data model doesn't enforce.
You're correct - you can't rely on the order in which instances are
fetched. OP, see the many previous threads in this list's archives
regarding sort order, etc. I usually create a sortOrder attribute.
Since you're dealing with transactions, perhaps you'll want to use a
date attribute. Use your fetch request's friendly 'sort descriptors'
to do the heavy lifting.
... of course, even if you use a predicate to specify a date range,
the transaction order still doesn't matter. I digress.
I gather from the OPs description that he's trying to compute the
balance after each transaction. The proposed approach is problematic:
1 - As Keary suggested, if the user edits a previous transaction's
amount, no balances will be updated (at least most likely not at the
expected time).
2 - Even using dependent keys (with the transaction instance's
-balance being dependent upon its -amount) won't help because changes
to other transaction instances will not trigger this dependency.
3 - Putting this logic in the model requires each instance to fetch
(and fire faults for) all transactions from the beginning of time up
to itself. Repeat this for every single transaction you want to show.
Ouch.
The best approach (also as Keary suggested) is to put this logic in
your controller. It's wasteful to put the responsibility of the
current balance on each individual transaction. A transaction is only
a debit or a credit, after all. A toaster, incidentally, is also just
a toaster. ;-)
To do this, I'd probably revert to the old table data source and
table delegate methods. Your balance column would not be bound to
anything. Instead, your table data source method would return the
total-balance-up-to-first-displayed-transaction plus the sum of all
transaction amounts (from first-displayed-transaction to the
transaction whose balance you're returning). This works particularly
well because:
1 - All the balance calculations (only for the displayed transaction
set) are done by your controller and not your model.
2 - This works since the order in which things are added and
subtracted are irrelevant for determining the final total and, though
you need a 'reference balance' up to the point you're displaying,
using set array operators should get you there quickly.*
3 - With relatively little work, you can easily bind some ivar of your
controller to the total-balance-up-to-first-displayed-transaction.
That way, each time the table is reloaded, the balances should be
calculated as few times as necessary.*
* One thing I'm speaking on that I'm not entirely sure of (mmalc?
Scott?) is whether a fault is fired if you're using the @sum set/array
operator when asking for @sum.amount ... I've never done this in
particular, hence the liberal smattering of 'should' in my
passive-aggressive assertions. :-)
--
I.S.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
