Wonder if anyone can see the obvious thing I seem to be missing here. I'm working on an app that uses a variety of Core Data entities. These entities store references to a variety of other source files. I want the availability/visibility of the Core Data objects to mirror the availability of the source files.
So at launch, I iterate through the sources and if available I add the NSManagedObjectID of any associated CD objects to an NSMutableSet, lets call it availableObjectIDs.
My understanding is that the using the predicate
"self IN..."
for Core Data should evaluate based on objects IDs, so in my fetch query I use the NSPredicate
"self IN %#", availableObjectIDs
This doesn't seem to be working properly. When I fetch objects with entity X, it returns objects whose objectID has not been added to availableObjectIDs. I can evaluate the results using
[availableObjectIDs contains:object.objectID]
and some will return false, even though the predicate should be filtering them out!
Stranger still, the identical predicate does appear to work when fetching entity Y. I cannot see any difference in the entity configurations to explain this. I've tried using an NSComparisonPredicate instead, and it seems to be behaving the same way.
Baffled by this seemingly simple issue. Anyone run into something similar?
Related
Based on some limited testing, I see that if I
Execute a Fetch request with result type = NSDictionaryResultType
Do some manipulations on the returned values
Store back the MOC on which Fetch request was executed
the changes in step 2 are not written back to the persistent store because I am changing a dictionary and not a "managed object". Is that a correct understanding?
Most likely you are abusing the dictionary result type. Unlike in conventional database programming, you are not wasting valuable memory resources when fetching the entire objects rather than just one selected attributes, due to an under-the-hood mechanism called "faulting".
Try fetching with managed object result type (default) and you can very easily manipulate your objects and save them back to Core Data. You would not need to do an additional fetch just to get the object you want to change.
Consider dictionaries only in special situations with huge data volumes, difficult relational grouping logic, etc., which make it absolutely necessary.
(That being said, it is unlikely that it is ever absolutely necessary. I have yet to encounter a case where the necessity of dictionaries for fetches was not an indirect result of flawed data model design.)
Yes, kind of, you can't store a dictionary back into the context directly so you can't save any updates that way.
If you get a dictionary object then you need to include in it the associated managed object id (if it isn't aggregated) or do another fetch to get the object(s) to update.
I am storing data in a table that has the columns "name" and "series". I am using this NSPredicate to query:
var request : NSFetchRequest = NSFetchRequest(entityName: "Entry")
request.returnsObjectsAsFaults = false
request.predicate = NSPredicate(format: "name = %# AND series = %#", name, series)
return request
The 'name' and 'series' variables are passed in as String arguments, which are also the data types on the table.
For some reason, this query returns no data. If I do a fetch request on this table without specifying a predicate I can see that the data is indeed there. I am not sure what I'm doing wrong.
For what it's worth I have tried enclosing the conditionals in parens but that didn't seem to make a difference either. Thanks in advance!
UPDATE: I've tried many different things but so far nothing is working. I'm really stumped.
For what it's worth it seems like I am having the same issue as this person: NSPredicate Returns No Results with Fetch Request, Works with Array Filtering
But, there isn't anything on that entry stating specifically what the solution to the problem was.
You can check if the data is there by
printing the URL of the application documents directory to the console.
going to this directory in Terminal
running sqlite3 <databaseName>
trying select * from z<entityName> where name = '<nameData>'
You will be able to explore the data and check if it contains what you expect. Don't forget to also check the content of your name and series variables in the code.
Oh wow...thank you everyone so much for all your answers. In the end it turned out that when I was populating the id for inserting a new row into the table, I was looking at a different table to calculate the new primary key id.
So I was overwriting existing records, which is why my query kept failing.
Kids, if you copy/paste your code without rigorously checking it, you're gonna have a bad time.
I have a Core Data layer with several thousand entities, constantly syncing to a server. The sync process uses fetch requests to check for deleted_at for the purposes of soft-deletion. There is a single context performing save operations in a performBlockAndWait call. The relationship mapping is handled by the RestKit library.
The CoreDataEntity class is a subclass of NSManagedObject, and it is also the superclass for all our different core data object classes. It has some attributes that are inherited by all our entities, such as deleted_at, entity_id, and all the boilerplate fetch and sync methods.
My issue is some fetch requests seem to return inconsistent results after modifications to the objects. For example after deleting an object (setting deleted_at to the current date):
[CoreDataEntity fetchEntitiesWithPredicate:[NSPredicate predicateWithFormat:#"deleted_at==nil"]];
Returns results with deleted_at == [NSDate today]
I have successfully worked around this behavior by additionally looping through the results and removing the entities with deleted_at set, however I cannot fix the converse issue:
[CoreDataEntity fetchEntitiesWithPredicate:[NSPredicate predicateWithFormat:#"deleted_at!=nil"]];
Is returning an empty array in the same conditions, preventing a server sync from succeeding.
I have confirmed deleted_at is set on the object, and the context save was successful. I just don't understand where to reset whatever cache is causing the outdated results?
Thanks for any help!
Edit: Adding a little more information, it appears that once one of these objects becomes corrupted, the only way get it to register is modifying the value again. Could this be some sort of Core Data index not updating when a value is modified?
Update: It appears to be a problem with RestKit https://github.com/RestKit/RestKit/issues/2218
You are apparently using some sintactic sugar extension to Core Data. I suppose that in your case it is a SheepData, right?
fetchEntitiesWithPredicate: there implemented as follows:
+ (NSArray*)fetchEntitiesWithPredicate:(NSPredicate*)aPredicate
{
return [self fetchEntitiesWithPredicate:aPredicate inContext:[SheepDataManager sharedInstance].managedObjectContext];
}
Are you sure that [SheepDataManager sharedInstance].managedObjectContext receives all the changes that you are making to your objects? Is it receives notifications of saves, or is it child context of your save context?
Try to replace your fetch one-liner with this:
[<your saving context> performBlockAndWait:^{
NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:#"CoreDataEntity"];
request.predicate = [NSPredicate predicateWithFormat:#"deleted_at==nil"];
NSArray *results = [<your saving context> executeFetchRequest:request error:NULL];
}];
First, after a save have you looked in the store to make sure your changes are there? Without seeing your entire Core Data stack it is difficult to get a solid understanding what might be going wrong. If you are saving and you see the changes in the store then the question comes into your contexts. How are they built and when. If you are dealing with sibling contexts that could be causing your issue.
More detail is required as to how your core data stack looks.
Yes, the changes are there. As I mentioned in the question, I can loop through my results and remove all those with deleted_at set successfully
That wasn't my question. There is a difference between looking at objects in memory and looking at them in the SQLite file on disk. The questions I have about this behavior are:
Are the changes being persisted to disk before you query for them again
Are you working with multiple contexts and potentially trying to fetch from a stale sibling.
Thus my questions about on disk changes and what your core data stack looks like.
Threading
If you are using one context, are you using more than one thread in your app? If so, are you using that context on more than one thread?
I can see a situation where if you are violating the thread confinement rules you can be corrupting data like this.
Try adding an extra attribute deleted that is a bool with a default of false. Then the attribute is always set and you can look for entities that are either true or false depending on your needs at the moment. If the value is true then you can look at deleted_at to find out when.
Alternatively try setting the deleted_at attribute to some old date (like perhaps 1 Jan 1980), then anything that isn't deleted will have a fixed date that is too old to have been set by the user.
Edit: There is likely some issue with deleted_at having never been touched on some entities that is confusing the system. It is also possible that you have set the fetch request to return results in the dictionary style in which case recent changes will not be reflected in the fetch results.
i have a problem. My iOS app is behaving really strange when it comes to fetching some data and having unsaved changes. For your interest the whole behavior appears while syncing some data with a web server. I wanted to do a full sync and then save the changes. I tried some workarounds but none of them was working well enough.
To the problem itself:
I sync some entities with a web server. They are organized into zones (their parent), which themselves are in a building. So for each entity i query if a matching zone already exists, and if not i create a new one. The problem now is that i'm unable to fetch those zones if they were just created (so a new but identical zone is created everytime). I also have the problem that i cannot fetch the correct building anymore once it is changed by adding a newly created zone to it, the result for the exact same query is suddenly empty.
I have ensured that [fetch setIncludePendingChanges:YES] is set, and i'm also using normal result mode not NSDictionaryResultType (see: NSDictionaryResultType expression not taking into account newly inserted objects).
I hope somebody can help.
A Fetch request fetches data from a context that has saved data in the persistent store from which the context is fetching. When you create a new Managed Object, you create it in your context (a.k.a. your scratch book) but not in your persistent store, yet. So before you can fetch a newly created object, you must save the changes of that context into your store.
Assuming that I understand your description right: I think your predicate for fetching your data is pretty complex, which forces core data to read from the persistent store. Thus, modifications in the managed object context are ignored.
For example we have a data model like
Category 1---n Icon
and we want to fetch all categories which
have icons (more than zero),
have icons whose attribute usable is TRUE
have icons whose attribute enabledByAdmin is TRUE
we use a predicate like this:
NSArray *predicates = #[[NSPredicate predicateWithFormat:#"icons.#count > 0"],
[NSPredicate predicateWithFormat:#"ANY icons.usable = 1"],
[NSPredicate predicateWithFormat:#"ANY icons.enabledByAdmin = 1"]];
NSCompoundPredicate *cp;
cp = [[NSCompoundPredicate alloc] initWithType:NSAndPredicateType
subpredicates:predicates];
This complex predicate forces core data to read from the persistent store, directly.
My solution is to save the managed object context and fetch the data afterwards.
In my core data object model I have 3 entities with appropriate relationships so that MyObject can have many MyObjectProperties, and each property can have one MyObjectPropertyImage.
Given a myObject I want to fetch all the images.
I try to do it using the following predicate, however I get an empty array:
[NSEntityDescription entityForName:#"MyObjectPropertyImage" inManagedObjectContext:managedObjectContext];
[NSPredicate predicateWithFormat:#"ANY myObjectProperty.myObject == %#", myObject];
Any ideas?
When working with Core Data it's best to think of your entities as just that: entities in an object graph, instead of tables in a database. Therefore, you don't need to fetch entities related to others using a predicate. Instead, navigate the object graph using the relationships defined in the model. To get all the images related to myObject:
// assuming the relationships are called 'myObjectProperties' and 'myObjectPropertyImage', respectively
NSSet *allImages = [myObject.myObjectProperties valueForKey:#"myObjectPropertyImage"];
Note that this may trigger additional trips to the database if your object graph is not loaded in memory for your myObject entity. To avoid that, make sure you set the pre-fetching relationship keypaths in your fetch request for myObject.
I hope this helps...
Since you have a MyObject instance in hand and it has the relationship path of myObjectProperties-->ObjectProperty-->>PropertyImages you just need to traverse the relationships. It's easy to do this with valueForKeyPath:
Thusly:
NSArray *images=[myObjectInstances valueForKeyPath:#"myObjectProperties.propertyImage"];
(Note: I might have your attribute names wrong but you can get the idea.)
As general rule, you never fetch when have an object from the graph available. You fetch to "pick out thread" of objects matching the predicate and then to find all related objects you follow the thread/relationships to the related objects.