views:

77

answers:

1

Hi

I parse an xml file containing books, for each new node I go:

Book *book = (Book*)[NSEntityDescription insertNewObjectForEntityForName:@"Book" inManagedObjectContext:managedObjectContext];

To obtain an NSManagedObject of my Core Data Book Entity, I then proceed to populate the managed Book object with data, add it to an array, rinse, repeat.

When I am done, I present the list of books to the user. I have not yet executed the save:

NSError *error;
if (![managedObjectContext save:&error]) {
    NSLog(@"%@", [error domain]);
}

The user now selects one of the books, this one I would like to persist, but only this one, all the other books are of no interest to me any more. The Book Entity does not have/or is part of any relationships. It is just a "single" Entity.

If I pull the "save lever" every Book object will be persisted and I will have to delete everything but my desired one.

How would I get around this challenge, I can't really seem to find that particular use-case in the Core Data Programming Guide, which sort of also bugs me a bit, am I going against best practice here?

Thanks for any help given.

A: 

Yes you are going against best practices. In that use case, if you really do not want to save the objects, keep them in an intermediate format and only create a Core Data object for the one you want to persist. However this seems quite wrong.

What is the harm in saving the other books? Are the only going to be used once ever?

Based on the small amount of information you have provided, it seems your approach to the problem needs to be reconsidered.

Update

Removing unsaved objects from the context has a very small overhead yes so that is the best solution given the parameters you have. I asked the other questions to see if there was a cleaner overall solution rather than building the objects just to throw them away. Sounds like you have already been down that path though.

Marcus S. Zarra
Hi Marcus and thanks.I can see there is not much info to work with. My main grievance with building intermediate objects is that I will have to build X implementations. There are use cases where I automatically add some books to the persistent store, where many books will be added and situations like above where only one should be persisted. I will also have to maintain Book and tempBook and populate the values from one to the other "manually", as far as I know, there is no "copy values from NSObject to NSManagedObject". Core Data is surely fast enough that it would keep things very 'clean'.
RickiG
ran out of characters.Yes books are mostly only used that one time.I also have "collections of books" entities(not containing actual books, just enough info to retrieve a set of books) that follows the above use cases, I have author entities and publisher entities that behaves in very similar manners.Using Core Data and NSPredicate I can keep things very transparent, with an overhead that is almost non existing.
RickiG
I found this one:http://stackoverflow.com/questions/1619911/how-do-i-create-many-temporary-objects-and-then-save-only-one-using-core-dataI went through the documentation again and it states that sending the deleteObject:Book message to a book that is not yet saved, has very little overhead as it simply removes the book from the context, no interaction with the store is needed.
RickiG
Hi MarcusYou are right, I do feel a bit uneasy building 50 Core Data Entities just to delete 49 of them before they are even saved.I have actually been pondering this for a couple of days now and the intermediate solution seems more right. I think if I parse directly to an NSDictionary and use that as data for the view, then migrating a single dictionaries values to a new ManagedObject is quite a small overhead, using setValuesForKeyUsingDictionay. If I name my variables in my Entity exactly as in the XML, I can go from XML->Dictionary->Entity without ever typing a Key string manually:)
RickiG