Re: predicate for a Core Data fetch request rejected by SQL
On Sat, 2010/03/06, Joanna Carter cocoa...@carterconsulting.org.uk wrote: This quote from the Core Data Programming Guide: There are some interactions between fetching and 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's functionality, including the comparison methods on NSString. The SQL 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, but it means that evaluation happens in a non-Cocoa environment, and so sort descriptors (or predicates) that rely on Cocoa cannot work. To my mind, this does state exactly what you have found. ? Sounds like 10% information and 90% hand-waving with no exactly about it. The reasonable thing to have in the doc after this is more precise descriptions of the differences, with several examples to show how it would work with and without SQL. But... after several tries searching from the doc home page, fighting the Evil Fremd Javascript, finally finding the right doc, reading through the page, I filed feed-back against the doc page. You should probably file your own, because the likelihood that we'd say things the same way, expressing exactly the same concern, including the same things and leaving out the same things, is tiny. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: predicate for a Core Data fetch request rejected by SQL
Hi Mark 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. ... 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. It is easy for someone like me to understand differences between how predicates work, because I have spent the last five years writing object persistence frameworks, which use predicates. However, it is another thing to explain that well founded knowledge to someone else who has never come across the concept :-) This quote from the Core Data Programming Guide: There are some interactions between fetching and 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's functionality, including the comparison methods on NSString. The SQL 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, but it means that evaluation happens in a non-Cocoa environment, and so sort descriptors (or predicates) that rely on Cocoa cannot work. To my mind, this does state exactly what you have found. I suppose all my experience has come from only ever writing predicate hierarchies against SQL storage mechanism, therefore I have only ever included predicate types that can be translated, primarily, into SQL. However, it is possible to use my SQL predicates against lists of objects but, obviously, not in such a comprehensive manner as the Cocoa-based extensions that Apple have provided. In my experience, as a consultant to companies who write business management software, the developers tend to come from a SQL background and, therefore, are quite surprised that a predicate hierarchy can cope with what they expect from an RDBMS. You, on the other hand, seem to have come from the other side where your experience started with XML and other non-SQL data storage. Therefore, you perceive the limitations of the SQL subset as a disadvantage. Maybe, one day, SQL parsers will be as comprehensive as the Cocoa ones :-) Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: predicate for a Core Data fetch request rejected by SQL
On 3/5/10 5:52 PM, Mark Sanvitale said: However, my experience seems to demonstrates that the statement We (the system) cannot necessarily translate arbitrary predicates into SQL queries is also true, It definitely is. 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. I agree the docs are weak here. I haven't looked in a while, but I don't recall seeing a list of which types of predicate don't with the SQL store. I've found this frustrating as I, like you, know nothing of SQL. The tools are also weak here. I don't know of any way for the compiler or static analysis tool to warn when a predicate will not work. But you'll find out at run time. :) In my case, it was painful because we switched from the XML store to the SQL store and it took a while to shake out all the 'bad' predicates. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
predicate for a Core Data fetch request rejected by SQL
RANT AGAINST DOCUMENTATION: I have searched (a lot) and found various other pleas for help of the form, I am trying to do a Core Date fetch on an SQL-backed store and it is failing because something is wrong with my predicate. I thought some investigate could promote my plea beyond this basic level, but I seem to be hitting the same wall-of-no-information as everyone else. This wall seems to built around Apple believing it's official Core Data docs adequately describes the issues with fetch predicates on SQL by stating, You cannot necessarily translate “arbitrary” SQL queries into predicates. Translation: The issue with predicates and SQL is that there are issues. Thanks for all the help, docs. BEGIN PROBLEM AND QUESTION: So, here is my plea for help. I have a predicate of the form: character string BEGINSWITH path. In other words, I am searching entities that possess a (string) property path to look for one whose path is a prefix of some string (which is inserted into the predicate via the fetch-request-template variable substitution). This fetch executes just fine on an XML store. The same fetch on an SQL store yields: unimplemented SQL generation for predicate (/Volumes/MacHD/Applications/Utilities BEGINSWITH path). My guess (given the lack of explicit documentation) is that SQL itself (or, perhaps, just Core Data's use of SQL) does not allow the left-hand-side to be a literal string, rather, it wants the left-hand-side to be a property key or key-path. Anyone know if this is actually the case? So far, in the world of path has to be on the left-hand-side I have not formulated a predicate that can determine if path is a prefix of the supplied string. Yes, I can fetch all entities from the DB and then do an in-memory search amongst the paths. Just hoping I could have the fetch do all the work. Mark Sanvitale Real Networks ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: predicate for a Core Data fetch request rejected by SQL
Hi Mark So, here is my plea for help. I have a predicate of the form: character string BEGINSWITH path. In other words, I am searching entities that possess a (string) property path to look for one whose path is a prefix of some string (which is inserted into the predicate via the fetch-request-template variable substitution). This fetch executes just fine on an XML store. The same fetch on an SQL store yields: unimplemented SQL generation for predicate (/Volumes/MacHD/Applications/Utilities BEGINSWITH path). You need to think about how a predicate would work against a SQL store. The left-hand side of the expression cannot be anything other than the name of a column or a path to the name of a column. Have you thought of using either path LIKE ... with wildcards, or path MATCHES ... with a regex expression? http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html#//apple_ref/doc/uid/TP40001795 is the page that discusses these ideas, look for the String Comparisons section. Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: predicate for a Core Data fetch request rejected by SQL
On 3/5/10 10:18 PM, Joanna Carter said: So, here is my plea for help. I have a predicate of the form: character string BEGINSWITH path. In other words, I am searching entities that possess a (string) property path to look for one whose path is a prefix of some string (which is inserted into the predicate via the fetch-request-template variable substitution). This fetch executes just fine on an XML store. The same fetch on an SQL store yields: unimplemented SQL generation for predicate (/Volumes/MacHD/ Applications/Utilities BEGINSWITH path). You need to think about how a predicate would work against a SQL store. 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. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: predicate for a Core Data fetch request rejected by SQL
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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: predicate for a Core Data fetch request rejected by SQL
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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
