I have a NSOrderedSet relaitonship on an entity. The order of the objects is correct until I save, quit and relaunch the app. Then, when the entity is fetched, For some instances of the entity, the order of this relaitonship is different from what it was prior to the relaunch. It's as if the NSOrderedSet completely forgot the order.
Inspecting the model file shows that this property is indeed ordered:
<relationship name="videoSegments" toMany="YES" deletionRule="Cascade" ordered="YES" destinationEntity="VideoSegment" inverseName="parentProject" inverseEntity="VideoSegment" syncable="YES"/>
I know about the autogenerated accessor code issue: Exception thrown in NSOrderedSet generated accessors however this is a different problem although it may be related somehow.
It doesn't forget anything, you should sort it. There is a difference between ordered and sorted.
Check NSMutableOrderedSet
If you need to return the data in a specific order, you need to add an attribute which defines the sort order, such as an index from 0..n, and sort the results on that.
CoreData doesn't pay any attention to the order in which you added the data
Related
I'm trying to efficiently batch delete a lot of NSManagedObjects (without using an NSBatchDeleteRequest). I have been following the general procedure in this answer (adapted to Swift), by batching an operation which requests objects, deletes, saves and then resets the context. My fetch request sets includesPropertyValues to false.
However, when this runs, at the point where each object is deleted from the context, the fault is fired. Adding logging as follows:
// Fetch one object without property values
let f = NSFetchRequest<NSManagedObject>(entityName: "Entity")
f.includesPropertyValues = false
f.fetchLimit = 1
// Get the result from the fetch. This will be a fault
let firstEntity = try! context.fetch(f).first!
// Delete the object, watch whether the object is a fault before and after
print("pre-delete object is fault: \(firstEntity.isFault)")
context.delete(firstEntity)
print("post-delete object is fault: \(firstEntity.isFault)")
yields the output:
pre-delete object is fault: true
post-delete object is fault: false
This occurs even when there are no overrides of any CoreData methods (willSave(), prepareForDeletion(), validateForUpdate(), etc). I can't figure out what else could be causing these faults to fire.
Update: I've created a simple example in a Swift playground. This has a single entity with a single attribute, and no relationships. The playground deletes the managed object on the main thread, from the viewContext of an NSPersistentContainer, a demonstrates that the object property isFault changes from true to false.
I think an authoritative answer would require a look at the Core Data source code. Since that's not likely to be forthcoming, here are some reasons I can think of that this might be necessary.
For entities that have relationships, it's probably necessary to examine the relationship to handle delete rules and maintain data integrity. For example if the delete rule is "cascade", it's necessary to fire the fault to figure out what related instances should be deleted. If it's "nullify", fire the fault to figure out which related instances need to have their relationship value set to nil.
In addition to the above, entities with relationships need to have validation checks performed on related instances. For example if you delete an object with a relationship that uses the "nullify" delete rule, and the inverse relationship is not optional, you would fail the validation check on the inverse relationship. Checking this likely triggers firing the fault.
Binary attributes can have data automatically stored in external files (the "allows external storage" option). In order to clean up the external file, it's probably necessary to fire the fault, in order to know which file to delete.
I think all of these could probably be optimized away. For example, don't fire faults if the entity has no relationships and has no attributes that use external storage. However, this is looking from the outside without access to source code. There might be other reasons that require firing the fault. That seems likely. Or it could be that nobody has attempted this optimization, for whatever reason. That seems less likely but is possible.
BTW I forked your playground code to get a version that doesn't rely on an external data model file, but instead builds the model in code.
Tom Harrington has explained it best. CoreData's internal implementation apparently requires to fire fault when marking an object to be removed from the persistent store, just like it would if you were accessing a property of the object. As explained in this answer, "An NSManagedObject is always dynamically rendered. Hence, if it is deleted, Core Data faults out the data".
This seems to be the normal behaviour at least for the moment being, not really an issue.
I wish to save a dictionary containing some Core Data objects (bunch of different entities). The objects also have quite a few relationships (and inverse relationships) defined. What would be the best way to go about it?
I tried using NSKeyedArchiver and writing to a file. While that works great, when trying to read from the file using NSKeyedUnarchiver, it fails on one of the classes with the error
-[SomeEntity initWithCoder:]: unrecognized selector sent to instance
EDIT - More details
I have a bunch of objects, each having properties based on which they can be filtered. The properties are in themselves Core Data entity objects since they have a complex structure.
I wish to save the filters the user has selected so that the next time they view the objects, the objects can be filtered as per their previous selection.
Say there are 3 filters, Filter A, B and C and each can have 5 different values. Now the user might select Filter A1, A2, B1 and C3 (or a different combination). My question, how do I save these selected filters (A1, A2, B1 and C3 in this case) using Core Data?
Let me see if I understand your question: You have a collection of managedObjects that are already saved in a context. They may already be persisted in the SQL database. You want to save that collection ALSO to another file for other purposes. You have already considered saving the information of this collection inside core-data in some way and have already rejected it. You have also considered simply saving the query generation tokens to save the state of the database as it currently is, but that also is not what you want. The point is to have a file that contains a copy of some of the managedObjects organized in a way that you can get the data back without using the SQL database that was already designed exactly for that purpose.
Solution 1: Turn each managed object in a dictionary.
You can get every attribute and every property of every object by getting a managed object's entity and then accessing the attributesByName and
relationshipsByName property of the entity. From there you make a simple loop to put each property into a dictionary. I also suggest you store the objectID and point to the objectID when encoding the relationships. Then replace the managedObject in your dictionary with dictionary that contains all the attributes and relationship. This new dictionary should be easy to archive and unarchive.
This make sure that the data when you unarchive is exactly how you left it. When you unarchive you will get a COPY of data and if the managed objects have changed in your database since then, you will get the OLD values. Also these copies are not core-data object because they are unconnected to a managed Object Context.
Solution 2: Just save the Managed Object's ObjectId.
Replace every managed object in your collection with the object's objectId. This dictionary can be easily archived. When you unarchive it replace every objectId with a core data object (if found) using existingObjectWithID: on the context. If entities have been deleted then you won't get them back. If entities have changed then you will get the NEW values.
Solution 3: Don't do any of this
It seems to me that you may not be aware core-data are already saved in a database. If you have some collection of managedObjects, you should be able to recreated it from your database. If you aren't able to, then you should add properties and/or relationships that will allow you to so.
Try like this :
ARCHIVE :
NSDictionary *yourDictData = [NSDictionary dictionaryWithObject:json forKey:#"key"]; // This is for example. Here you have to replace ur dictionary
NSData *myData = [NSKeyedArchiver archivedDataWithRootObject:yourDictData];
UNARCHIVE :
NSDictionary *myData = [NSKeyedUnarchiver unarchiveObjectWithData:yourDictData];
I'm using Realm.io as database and I need a select * from all_tables in Realm.
I mean a method returning an RLMArray, but I have not found anything about this.
I need the class reference, such as Realm Browser.
Thanks.
You can use [realm.schema.objectSchema valueForKey:#"className"] to get an NSArray of all of the RLMObject subclasses used in the Realm.
I don't believe this is possible at the moment. You should request it on github. In the mean time you will have to create your own. First you have to know that an RLMArray can only hold one type so if in these different tables there are different types than you can not do the following. It would be as easy as creating your own method for this. It would consist of getting all objects from each table and just inserting them into the RLMArray; If your tables don't have the same type then you will have to use a NSMutableArray or an NSArray.
We have a bunch of NSManagedObjects of various types.
Some of them have members that are NSSet's of other NSManagedObjects.
The problem is that I really need to override the hash and isEquals methods of the objects that are IN the set - but they are NSManagedObjects.
I'm having problems with getting multiple identical objects in the set.
As far as I can tell, since hash defaults to the object address - all objects are different. So I need to override hash and isEquals - but can't see any way to do it.
What we have is a bunch of stuff in the System, and more comes in via XML - sometimes repeats of the existing objects. When they are the same, I don't want dups added to the set.
As mentioned above by Wain, NSManagedObject documentation states that you must not override hash or isEqual:. So this means a stock NSSet does not do what you need.
Some of your options are:
Enumerate the NSSet contents to identify and remove duplicates
Write a factory method for your NSManagedObjects that will return the same object when given the same inputs
Fix the XML to not include duplicated objects
Unique the objects coming from the XML before they become NSManagedObjects
Modify the input XML to include a unique identifier that you can track, assuming the duplicated objects are exact duplicates
Implement your own NSSet-like collection class that performs a different uniquing test than hash and isEqual:
In the documentation and in the broad literature the generated factory method to delete/remove a subclassed managed object in CoreData for IOS is
(void)removeXXXObject:(NSManagedObject *)value
where XXX is the corresponding relationship or we can use simply removeObject.
In my code I used this:
Data *lastData = [[self sortedPersonDatas] objectAtIndex:0];
[selectedPerson removePersonDatasObject:lastData];
where PersonDatas is a one-to-many relationship to Data managed object from I took the last data (lastData resulted from a sorted array of all data)
But using the first two remove methods and checking the SQL database behind we can find that the actual data is existing just the inverse relationship is null.
To completely delete the data (all attributes and the object) I had to use:
[selectedPerson.managedObjectContext deleteObject:lastData];
The question: which is the better method and is it correct that CoreData leaves the data intact?
removeXXXObject only removes an object from a to-many relationship, but does not delete the object from the store. To do so, you have to indeed use deleteObject - this is the desired behavior. Calling deleteObject will by default also set the corresponding relationships to nil (see https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdRelationships.html#//apple_ref/doc/uid/TP40001857-SW1).