What is the best way to handle temporary objects in Core Data? I've seen solutions where temporary contexts are created, where they are inserted into nil contexts, etc.
However, here's the issue I'm seeing in both of these solutions. I'm using Core Data for my object model and and in some of my views store a NSSet of Core Data objects. The problem I have is when the object is stored, the objectID changes which effectively invalidates anything stored in any NSSet since the isEqual and hash are now different. While I could invalidate the object stored in the NSSet, it often is not practical and certainly not always easy.
Here's the things I've considered:
1) override isEqual method and hash on NSManagedObject (obviously bad)
2) do not place any NSManagedObject in a NSSet (use a NSDictionary where the key is always fixed)
3) use an entirely different type to store in NSSet where I could correctly implement the isEqual and hash code methods
Does anyone have a better solution for this?
ManagedObjects in an NSSet -- that sounds like a Core Data relationship. Why not simply store your temporary managedObjects in a relationship, and have Core Data take care of the problems you're now running into. Then you can concentrate on when and how to delete the temporary objects, or break the relationship or whatever is needed.
However, here's the issue I'm seeing in both of these solutions. I'm using Core Data for my object model and and in some of my views store a NSSet of Core Data objects. The problem I have is when the object is stored, the objectID changes which effectively invalidates anything stored in any NSSet since the isEqual and hash are now different.
tjg184,
Your problem here is not the transition to permanent IDs but that your container class depends upon an immutable hash. Hence, change your container class to an array or dictionary and this problem goes away. (You give up uniquing with an array but that is easy to handle with a trip through a transient set to perform the uniquing.)
Andrew
A possible solution would be to convert the temporary IDs to permanent ones using [NSManagedObjectContext obtainPermanentIDsForObjects:error:].
But be aware that this may be expensive, especially if you have a lot of objects you need to process this way.
You could possibly subclass NSManagedObject and override the willSave and didSave methods to remove and then re-add you objects to your set.
I actually ended up using a different approach, that of using a NIL context and providing a base class to handle insertion into a context. It works really well and is the cleanest solution I have found. Code can be found here... Temporary Core Data
Related
So in my Core Data relationships, I have an object with a relationship to other objects that is mapped via an NSSet. When I get my primary object, I will want to iterate over the NSSet. Just iteration, nothing fancy.
Now, according to this article, NSArray is much faster than NSSet. http://www.cocoawithlove.com/2008/08/nsarray-or-nsset-nsdictionary-or.html
My NSSet will never be that big, so I don't think it really matters in this case. However, I just wanted to know in general, is the overhead of converting a NSSet to NSArray for iteration still faster overall?
Thanks!
Converting an NSSet to an NSArray will require iteration over the set, as well as allocating memory for the array so just iterating over the set will be faster unless you're going to iterate over it repeatedly.
But in either case, even with quite a large set, we're likely talking nanoseconds. I really wouldn't worry about it unless you've profiled an actual performance issue and the data tells you its a problem.
Also, the performance figures you've linked only really apply for collections you create yourself. When you get a collection back from a framework, it can (and in the case of core data, will) return you a collection with a custom implementation that has its own performance characteristics.
I have a question regarding the addition of multiple CoreData entries in multiple tables.
I have the following code:
while((item = [enumerator nextObject]))
{
DOCategory *cat;
cat = [[self categoryController] getNewCategory];
[cat setName:[item objectForKey: #"name"]];
[cat setDesc:[item objectForKey: #"description"]];
[cat setLastUpdate:updateTime];
//[[self categoryController] commitChanges];
}
I used to call the commitChanges after each enumeration, and that works, but takes a long time, especially on older devices as the initial load is quite substantial. Therefore I just want to save at the end of the whole operation.
What is the best way to add all those objectors to a NSSet (or NSArray) while preserving the link to the ManagedContext. Normally I would 'copy' them into the set, but that doesn't work here. A simple question, just have a block to seeing the best solution.
(I assume that I don't have to 'commit/save' after every new object I created, so the results are not written to the database yet, but are available for searches as there are different relational objects in the procedure)
Update:
After the suggestion below and more testing, it appears to me that when I haven't saved/committed the context it is not included NSFetchResultController. Is this right and supposed to be the way? Is there a way to do all the operations (including searches to create relations) in 'cache' and then commit once all is done?
Update 2:
In order to get the Managed Object I have a procedure in the Controller-class:
- (DOCategory *) getNewCategory{
return (DOCategory *)[NSEntityDescription insertNewObjectForEntityForName:#"Category" inManagedObjectContext:managedObjectContext];
}
It appears that the code runs fine, including cross references, until I come to adding the final object which uses all the other managed objects. There must be some problem in that code.
Your code is old school Objective-C 1.0 so it would be best to update it. You seldom use enumerators directly like that anymore.
The best way to handle this is to create the new managed objects by inserting them into the context using +[NSEntityDescription insertNewObjectForEntityForName:inManagedObjectContext:] this both creates the managed object and makes the context aware of it. The context will retain the managed object itself. That's were the "managed" of "managed object" comes from.
The normal practice when making a lot of changes is to change all the objects and then save the context only when you are done making all the changes.
Update:
It appears that the code runs fine,
including cross references, until I
come to adding the final object which
uses all the other managed objects.
There must be some problem in that
code.
That sounds like you might have a problem with the relationship being set properly in the data model itself. I can't say for certain without knowing what your data model looks like.
I discourage the use of cast with insertNewObjectForEntityForName: e.g.
(DOCategory *)[NSEntityDescription insertNewObjectForEntityForName:#"Category" inManagedObjectContext:managedObjectContext];
... because if you have a data model problem, such as not providing the name of the DOCategory class for the DOCatergory entity, the cast will obscure the problem. If there is no class defined the method will return an instance of the generic NSManagedObject class or if you accidentally define the wrong class for the entity e.g. MadeUpClassName instead of DOCategory then the cast will force the runtime to treat the returned object as a DOCategory object. That might work fine until way down in the code.
...it appears to me that when I haven't
saved/committed the context it is not
included NSFetchResultController. Is
this right and supposed to be the way?
Is there a way to do all the
operations (including searches to
create relations) in 'cache' and then
commit once all is done?
Not exactly sure what problem you are seeing. It is best practice to make all changes to all objects and then to save the context instead of saving after every change to any single object. Disk operations are expensive.
If your changes to the context are not reflected in the NSFetchResultsController (FRC) then you most likely did not implement the FRC delegate methods that update the tableview (see FRC docs.) Another possible error is that you've created two context accidentally. If you are using threads, each with a separate context (required practice) then you have to merge the background context with the front context before the changes made in the background are made known to the foreground.
Let's say variable A and B hold instances of managed objects in the same managed object context. I need to make sure that they are associated with the same "record" in the persistent store. The section on Faulting and Uniquing in the Core Data Programming Guide says that:
Core Data ensures that—in a given managed object context—an entry in a persistent store is associated with only one managed object.
From this, it seems that a pointer comparison is sufficient for my purpose. Or does it ever make sense to use isEqual: to compare managed objects in the same context?
Use == to determine if two pointers point to the same object. Use -isEqual to determine if two objects are "equal", where the notion of equality depends on the objects being compared. -isEqual: normally compares the values returned by the -hash method. I wrote previously that it seemed possible that -isEqual: might return true if two managed objects contain the same values. That's clearly not right. There are some caveats in the docs about making sure that the hash value for a mutable object doesn't change while it's in a collection, and that knowing whether a given object is in a collection can be difficult. It seems certain that the hash for a managed object doesn't depend on the data that that object contains, and much more likely that it's connected to something immutable about the object; the object's -objectID value seems a likely candidate.
Given all that, I'm changing my opinion ;-). Each record is only represented once in a given context, so == is probably safe, but -isEqual: seems to better express your intention.
Pointer comparison is fine for objects retrieved from a single managed object context, the documentation on uniquing you quote promises as much.
ObjectID should be used for testing object equality across managed object contexts.
isEqual does not do attribute tests, because it is documented to not fault the object. In fact, looking at the disassembled function it is definitely just a pointer compare.
So the semantics of the equality test for managed objects are simply "points to the same object (record) in the managed object context" and will compare false for objects in different contexts.
Warning: Since NSManagedObject isEqual compares objectIDs, a comparison can fail if one instance is using the temporary objectID and the other instance is using the permanent objectID.
Background: When an NSManagedObject is created, it is assigned a temporary objectID. It is converted into a permanent objectID when the NSManagedObject is actually persisted into the store. You can see the difference if you print the objectID:
x-coredata:///MyEntity/t03BF9735-A005-4ED9-96BA-462BD65FA25F118 (temporary ID)
x-coredata://EB8922D9-DC06-4256-A21B-DFFD47D7E6DA/MyEntity/p3 (permanent ID)
When an objectID is converted to permanent, instances of the NSManagedObject in other threads and collections are not updated. So if you put an NSManagedObject into an NSArray when it has a temporary objectID, using methods like containsObject will fail if you try to find the object with the permanent objectID. Remember containsObject uses isEqual.
Finally, a couple of useful methods are NSManagedObjectID isTemporaryID and NSManagedObjectContext obtainPermanentIDsForObjects:error:.
I'm trying to create a semi-complex set of view animations (think an animated version of an NSMatrix form, where rows slide around as other rows are added or removed), and to build the animation I'm making a little helper class.
There I have to keep track of the different views, their ordered indices, and few some other values associated with their animations.
To that end, I'm using an NSArray instance to keep track of the ordering (indices) of the views, and I'd like to use an NSDictionary with the views as keys to keep track of the values (the values themselves are in nested dictionaries). I.e. I'd like to be able to do something this, for instance (pseudo code):
NSMutableDictionary* viewValuesDict = [NSDictionary dictionary];
// Loop thru an ordered NSArray
for( (NSView*) view in viewsArray ) {
// Get some values we'll need later
NSDictionary* associatedValues = [view getSomeValues];
// ...and put them into viewValuesDict...
[viewValuesDict setObject:associatedValues forKey:view];
// and then things break because the NSView 'view'
// doesn't support copyWithZone.... darn
}
Problem is, I of course can't use NSView instances as dictionary keys, because the keys are added using copyWithZone, which NSView does not implement.
So, what's a good way to get a unique key for an NSView instance? I could conceivably use [obj description] since the memory address you get back is a perfect UID, but of course the system has to work with any kind of NSView subclass that might return something else entirely, so that's no good.
Or should I maybe try something else entirely? Is there maybe some alternative to NSDictionary, where keys just aren't copied? Because in this case I really have no need for the keys to ever be copied.
Sometimes there are occasions where you want to use a view (whether NS or UI) as the key in a dictionary. I've come across one such situation. I would've preferred to use objc_setAssociatedObject, but that requires Snow Leopard. Boxing with NSValue will work, but if you need to be doing lots and lots of look ups given a view, the continual boxing and unboxing of pointers may become tedious.
There are two options to creating an NSView => <object> dictionary.
Use NSMapTable
Use CFMutableDictionaryRef
NSMapTable is a class introduced in 10.5 that is very similar to an NSMutableDictionary, except that it has extra abilities that make it work more nicely with garbage collection. In your case, you'll probably want a map table with "weak" keys and "strong" values, but read the documentation for all the fun details.
CFMutableDictionaryRef is the Core Foundation equivalent of an NSDictionary (they are toll-free bridged), but it has some extra creation options. You create one using CFDictionaryCreateMutable(), and that wants two struct parameters. One is a structure that defines the memory management (and other) behavior of how to deal with the keys of the dictionary, and the other is a struct for defining the behavior of the values. You can create a CFMutableDictionaryRef with the options of retaining the keys (instead of copying them) and then retaining the values. Once you've done this, you can cast the CFMutableDictionaryRef to an NSMutableDictionary and use it as you'd expect, just that the keys will be retained instead of copied.
Use NSMapTable instead of NSDictionary (of course you'll have to be sure to manage your object lifetimes carefully if you're not using garbage collection). This article has a good summary of how to use it.
As andyvn22 said, reorganize! But if that isn’t practical:
If you’re targeting Snow Leopard, and the associations are likely to persist for the lifetime of the views, use objc_setAssociatedObject().
Otherwise, use [NSValue valueWithNonretainedObject:] in preference to -description. (Like it says, it doesn’t retain the object, but your array does.)
Create your dictionaries so that one of their values is the view; then rearrange the code so that you need not look up dictionary based on view, but rather begin either with the dictionaries, or the index (putting the dictionaries into an array), or a unique ID of your own creation (putting the dictionaries into a dictionary; the ID could be as simple as a consecutive number for each new view you begin to keep track of). Unless you're doing something very complicated and dynamic, it should be possible to avoid needing to look up information given only an NSView.
I am fairly new to Objective-C and was wondering what the best way to manage collections of tuples was. In C I would use a 2D array or a struct.
Should I be creating objects to contain these tuples? It seems like overkill for just sorting lists or is there no real extra load generated by object initialisation?
There definitely is some overhead in the generation of objects. For a small number of objects, then using ObjC data structures is still appropriate. If you have a large number of tuples, I would manage them in a C array of structs. Remember, Objective-C is really just C. It is appropriate and common to use C constructs in Objective-C (to a point; learning where that point is represents a major milestone in becoming a good Objective-C developer).
Typically for this kind of data structure, I would probably create a single Objective-C object that managed the entire collection. So external callers would see an Objective-C interface, but the internal data would be stored in a more efficient C structure.
If it is common to access a lot of tuples quickly, my collection object would probably provide "get" methods similar to [NSArray getObjects:range:]. ObjC methods that begin with "get" indicate that the first parameter is a pointer that will be overwritten by the method. This is commonly used for high-performance C-like access to things managed by an ObjC object.
This kind of data structure is exactly the way ObjC developers merge the elegance and maintainability of ObjC with the performance and simplicity of C.
I think you'll have to settle for an NSArray of NSArray objects, or maybe an NSArray of NSDictionary objects. You can always roll your own class, or do it the way you would do in C.
There are a couple different ways you could go about this:
CoreData. While it's not technically a database, it can behave a lot like one. If you don't need persistence between app runs, then consider using the NSInMemoryStoreType store type, as opposed to an NSSQLiteStoreType or other option. However, if you're going to want to join tuples together, using CoreData will absolutely not work (this, IMO, is the main reason why CoreData is not a database).
Use a real database. SQLite ships on every Mac and iPhone and is pretty easy to use if you use wrappers like FMDB or SQLite Persistent Objects or PLDatabase or EGODatabase or the GTMSQLite wrapper by Google.
A tuple is really just a collection of key-value pairs, so you could just use an NSMutableArray of NSMutableDictionaries. You obviously won't get to use SQL syntax, and any joins/queries you have to run yourself, but this would definitely have the easiest setup.
Write a tuple class and store those in an NSMutableArray (similar to #3, just enforcing a common set of attributes on your tuples).