danu
danu

Reputation: 1188

Filter Vs NSPredicate in coredata

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.

Upvotes: 3

Views: 504

Answers (2)

Martin R
Martin R

Reputation: 539975

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.

Upvotes: 4

Paulw11
Paulw11

Reputation: 114984

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.

Upvotes: 1

Related Questions