> 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]
