Filter Vs NSPredicate in coredata

user_7199577 0
Viewed 236

I know that you cannot treat coredata as a relational database since its an object graph (correct me if im wrong). Therefore, Im a bit lost in terms of what happens in the memory when u call a fetch request with a predicate.

  1. Would that first load the entire entity to the ManageObjectContext and then do the filtering with the help of the predicate, or would it directly do the filtering as a relational database (Directly picks the value from the table like a select query works in a relational DB) ??

  2. If it loads the entire entity to the memory why not use "filter" instead of "NSPredicate"

An answer with proper Apple referencing would much appreciate.

swift core-data objective-c ios
2 Answers

From Persistent Store Types and Behaviors in the Core Data Programming Guide (emphasis added):

Fetching differs somewhat according to the type of store. In the XML, binary, and in-memory stores, evaluation of the predicate and sort descriptors is performed in Objective-C with access to all Cocoa functionality, including the comparison methods on NSString.

The SQLite store, on the other hand, compiles the predicate and sort descriptors to SQL and evaluates the result in the database itself. This is done primarily for performance, ...

You can verify that by enabling Core Data debugging. Set

-com.apple.CoreData.SQLDebug 3
-com.apple.CoreData.Logging.stderr 1

as environment variables and you'll see the SQLite statements as they are executed.

user_11874150

The answer is "it depends". Fetch requests are dispatched to the Core Data Store you are using. It is up to that store as to how it handles the fetch requests.

The SQLite store that is most commonly used with Core Data translates predicates into an SQL query. Other store types may not be able to do this and may need to perform filtering in memory.

user_34180660
Related