Re: predicate for a Core Data fetch request rejected by SQL
Re: predicate for a Core Data fetch request rejected by SQL
- Subject: Re: predicate for a Core Data fetch request rejected by SQL
- From: Mark Sanvitale <email@hidden>
- Date: Fri, 5 Mar 2010 17:52:45 -0800
- Old-return-path: email@hidden
Thanks all for the sharing of thoughts. Glad someone could confirm that what I was attempting did not make sense from the SQL perspective (which I am a newbie to). But, like Sean wrote, Core Data seems to be presented as an abstraction ABOVE the layer which implements the actual storage/retrieval, thus, having to know about SQL details to get a Core Data operation to execute properly is unfortunate.
Some additional thinking about things made me realize that my rant about how the docs had failed me was a bit misdirected. I pointed at the line, "You cannot necessarily translate “arbitrary” SQL queries into predicates" as being unacceptably vague. I now think that this statement is acceptable. Since Core Data is a concept separate from (though related to) SQL, you cannot expect to be able to bring every SQL-ism into the Core Data world and have it function properly (i.e. SQL ≠ Core Data).
However, my experience seems to demonstrates that the statement "We (the system) cannot necessarily translate “arbitrary” predicates into SQL queries" is also true, and I believe this concept should be expanded to spell out exactly what generally legal predicates end up being illegal when applying them to a Core Data context that is backed by SQL. The only expanded discussion I can find on this subject in the official docs is, "predicates that rely on Cocoa cannot work", which, for me, does not shed enough light on the subject.
Mark
On Mar 5, 2010, at 3:45 PM, Joanna Carter wrote:
> Hi Sean
>
>> But you shouldn't have to... Core Data is "not a database" and its use
>> of SQL is an implementation detail. One shouldn't have to know anything
>> about SQL to use Core Data. Of course, in practice, such knowledge is
>> helpful, as you say.
>
> You have a point but, in theory, predicates against lists of objects usually take either the form:
>
> <value of a property> <operator> <constant value>
>
> ... or possibly:
>
> <value of a property> <operator> <value of another property>
>
> Some predicates might be usable between two constant values but I have never seen one used, even with lists of objects, as:
>
> <constant value> <operator> <value of a property>
>
> Such a construct might work in the context of an XML file because the lefthand term could be interpreted as the name of a key but, not normally in a where clause in a database.
>
> Joanna
>
> --
> Joanna Carter
> Carter Consulting
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden