Strategy for core data sales register

I have been trying to use a second managed object context (MOC) in core data to add sales which will be listed in an NSTableView as pending, until the user presses a button to process the transactions.

Upon pressing the button, the 2nd context is saved, and the NSManagedObjectContextDidSaveNotification does trigger mergeChangesFromContextDidSaveNotification on the main context.

S开发者_StackOverflowo far OK. But, next I need to clear the second context so that the following sale transaction is on a blank MOC. Also to clear it by a cancel action or change of user.

Seems that the clearing of the second MOC is not possible... and I have become convinced after searching for a solution that this is not an viable core data pattern. Instead I am now backtracking to use only one context. However, the current sale now displays all transactions, where I would only want the current ones. Again, if I could list the current "pending" transactions there, have a "cancel" button to undo these if necessary; and clear the table after the "process sale" button, would achieve similar means of managing the transactions.

So I am now stuck since there is no obvious way to identify "current" / pending transactions from other recent ones.

I need a two step data entry. (1) add sales, edit, etc. (2) process i.e. commit these sales

So the first strategy now seems in principle OK and is suggested by ( http://developer.apple.com/library/mac/#documentation/DataManagement/Devpedia-CoreData/managedObjectContext.html ) and also in this tutorial ( http://www.timisted.net/blog/archive/multiple-managed-object-contexts-with-core-data/ )

Yet the method used in that tutorial only keeps a single managed object in the 2nd context and copies / deletes as required.

Is the best strategy to use the first approach with a second MOC, and copy & delete the transactions rather than merge ?

Or is there a simpler solution that I am not seeing yet ?

Hope this question makes sense :-) and any help appreciated

---

Simply introduce a status attribute for your transaction entity where you keep the information about pending transactions. During entry, save frequently (which is not too expensive because of very little data). In this way, you can shut down the app completely and resume exactly where the user left off by reconstructing the same situation from the persistent store...

In any case, your strategy to move to one MOC is the right one.

---

On the technicality of implementing the solution, wanted to share the method, as it seems very hard to make sense of interface builder in relation to applying a predicate to the results. Actually I have wasted some time looking for a convenient way to leverage the bindings and interface builder.

So, what seems to work is to add custom NSArrayControllers for each output table. In the pending sales table, bind to the SalesController; I just subclass NSArrayController and then make the change in awakeFromNib as shown below. The commented out line is the attempt that made no impact at all, so I don't really understand the role of fetch predicate but setting a filter predicate does have the desired effect. For listing confirmed transactions, its the same but with "pending==NO"

-(void)awakeFromNib {
 //    [self setFetchPredicate:[NSPredicate predicateWithFormat:@"pending == YES"]];

    [self setFilterPredicate:[NSPredicate predicateWithFormat:@"pending == YES"]];
}