In SimpleTodo, Simperium says
Simperium starting...
Simperium loaded 1 entity definitions
Simperium managing 2 Todo object instances
Simperium found an existing auth token for myemail#myhost.de
Simperium starting network managers...
after init and start.
When starting Simperium in my own app the line saying Simperium managing x MyEntity object instancesis missing. It says Simperium loaded 15 entity definitions, though.
The datamodel of my app is quite complex (hence the 15 entities) and I didn't introduce a SPManagedObject in my datamodel. But I changed all NSManagedObject superclasses to SPManagedObject and added the two attributes ghostData and simperiumKey to all entities.
What can I do to check if all is good? What do I have to do, to make it manage my entities?
We pushed a fix for Entity names tonight that should help with the problem you're having. It should now be possible to specify the ghostData and simperiumKey attributes manually if you prefer complete control over your table structure (as discussed in Inherit from SPManagedObject).
Related
I have a Core Data data model where I have two similar, but not same, entities. I took the common attributes and stuck them in an abstract entity. I marked the abstract entity as a parent entity of the two original entities in my data model.
I can generate NSManagedObject subclasses without issue, and in code, I can manipulate attributes of instances of either child entity and have the app compile fine.
One of the child entities works just fine in runtime. However, when I attempt to mess with entity-only attributes on the other child entity, I get a crash with an
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[KUNLearnedItem setWord:]: unrecognized selector sent to instance 0x7ffec0d08ee0'.
If I turn off the parent/child relationship for the one entity and regenerate NSManagedObject subclasses, I can manipulate the attributes just fine.
Any thoughts? I've been pulling my hair out for days over this.
It was a bug related to finding the entity name in the core data library I was using. I installed and used Mogenerator to generate NSManagedObject subclass files and all is well.
I am trying to add a new entity in NSManagedObjectModel in my NSIncrementalStore Subclass. I am doing this in loadMetadata method but it keeps throwing this exception on the last line. See Code Below
"NSInternalInconsistencyException" Entities for a configuration must already be in the model
Code
var model:AnyObject=(self.persistentStoreCoordinator?.managedObjectModel.copy())!
var newEntity=NSEntityDescription()
newEntity.name="newEntity"
newEntity.managedObjectClassName="newEntity"
var entities=model.entitiesForConfiguration(self.configurationName)
entities?.append(newEntity)
model.setEntities(entities!, forConfiguration: self.configurationName)
You cannot modify a model after it has been added to a persistent store coordinator. The only time you can manipulate the model is just after initialization and before applying it to the NSPersistentStoreCoordinator.
The documentation is unclear about this, but before calling setEntities:forConfiguration: the entities being set must already exist in the managed object model's entities array. This is because this method actually assigns existing entities in the model to a particular configuration.
The solution here is to make a mutable copy of the entities array, add your entities to it if they do not exist, and then set the managed object model's entities array to an immutable copy of the modified array.
After that point you can invoke setEntities:forConfiguration:.
It would be worth filing a radar bug report on this behavior.
I am using the core data stack shown in the image below. I want to design a structure where objects can be created in both worker contexts.
What I am observing in the setup is if both contexts try to create the same object (for a unique key) at around the same time, db ends up in creating two rows for the table. Is there a way to solve this? Thanks in advance for your response.
The only way you can ensure uniqueness would be to have a coordinating object that all contexts turn to to verify their operation (a "uniqueness enforcer" if you will).
The general algorithm is described HERE, however you fall under the "multi-threaded/context" category and this will complicate things.
In a multi-threaded environment, your enforcer would have to perform a save to the store (using its own managed object context) before returning results to the calling object.
The general flow would be (no cache version):
A context request object for keys from the enforcer
The enforcer issue the request "under lock" (either locking an actual lock or using a serial dispatch queue)
the enforcer query the store for existing objects
create objects for missing keys and save them
you might want to mark the objects as stubs, as the caller might not eventually save and it will give you a flag to ignore them in your fetch requests in your views
build the results array with the objects he created
the results might be NSManagedObjectIDs or imported objects in the caller context otherwise you risk cross context access of managed objects
I am using coredata to save the server data through web services in my application and I am storing relationships as an object to the entity.
I have many entities e.g "Inspirations" and "Products" and both are related to each other. I have a problem whenever the records are updated in the third entity which is "Filters" then the relations of the entities broke and I cannot apply filters on the entities.
[object addRelatedInspirationsObject:related];
This is how I save relationships. I am not able to figure out why the relations are being broken once the entity is updated which has no direct link with the entity.
One thing more if I fetch and save the data of any one of the entities like "Inspirations" then all the relations start to work again.
Your code should work. Here are 2 things you need to check:
Make sure related is not nil when you call your method.
Make sure you call save on a valid managed object context.
From your question it seems that entities have 1 to many relationship between them. And by the code you supplied, every things should work fine. Just make sure, you are using the Filter object from the relationship like object.filter (or obj1.obj2.filter), not accessing it via a direct NSPredicate on Filter entity and updating it. And if you are using FRC, you might also need to generate a fault against the parent entities, to get your UI updates.
This is a bit of a tricky one.
I have Document entities that are currently being imported into CoreData from a SQLite database on a background thread. There's a separate context for the background thread and I am batching the save at every 500 entries.
Saving the background thread context triggers a notification which grabs my main thread's contexts and performs a merge between the two.
Everything works as expected if I am only importing document entities.
My problem occurs when I try and establish a relationship between the current document being created, an another entity called briefcase.
This is what my import routine currently does:
Create Briefcase entity
Loops through SQLite database rows and creates Document entities for each row
Create the relationship between the document in the loop and the briefcase entity
At every 500 rows, I save & reset the context. This triggers a ContextSave notification which grabs the main thread and merges with the main thread's context.
This is where my issue is: after the save & reset above, my Briefcase entity gets merged with the main thread so when my loop continues, the next document entity created tries to associate itself with the briefcase, which is where I get a crash saying I can't establish relationships between objects on separate threads.
I know that if I remove the call to reset the context after saving it, everything works as expected but my memory footprint goes way up and it is not something I am prepared to accept.
So my question is:
Can you think of a way of keeping the Briefcase entity around (and valid) for the entire import process so I can continue to create the relationships?
My first thought was to create the briefcase entity without a context and then add it to the context once the whole process is finished. This didn't work very well (it crashed on creation).
Your thoughts are very much appreciated.
Rog
Answering my own question:
Create Briefcase entity
Loop through SQLite database rows and create Document entities for each row
Create the relationship between the document in the loop and the briefcase entity
At every 500 rows, save context & immediately store the objectID for Briefcase after saving
Now it's ok to reset the context
(Re)retrieve the briefcase instance using the objectID saved above and the existingObjectWithID:error: method
Loop continues...