The fact that Core Data "cannot fetch using a predicate based on
transient properties" [1] seems to greatly limit the utility of the
NSPredicateEditor view, and makes me very sad.
Dear list.
transient (adj):
(1) passing especially quickly into and out of existence
May I suggest that the expectation that Core Data should fetch based
on criteria that DOES NOT EXIST in the file seems somewhat
unrealistic ? However, enhancement requests are always welcome if you
can articulate a coherent solution to the existential limitation.
But there's an even better way. Upon further study of the Predicate
Programming Guide, I find that there are even more limitations to Core
Data fetches with predicates. The most troubling is that:
"The Core Data SQL store supports only one to-many operation per
query; therefore in any predicate sent to the SQL store, there may be
only one operator (and one instance of that operator) from ALL, ANY,
and IN."
Do you have a specific scenario in which you need to perform nested to-
many operations, yet you cannot use SUBQUERY or compound queries like
OR ? Or is this troubling, in the sense that the universe is doomed
to evaporate kind of way ?
A much better way appears to be to fetch all objects from the store
with no predicate and then use -[NSArray
filteredArrayWithPredicate:]. This takes only one more line of code,
solves all problems, and is supposedly cheaper too:
This does not solve all problems, it most emphatically is NOT cheaper,
and most assuredly does NOT scale.
The atomic file approach is convenient and extremely simplistic. It
also fails to scale gracefully past 10^2 objects.
Optimizing memory management is very important for launch time and
concurrency. The monster 8 core mac pro will be constrained by the
memory bus (vastly slower compared to the sum computational power) if
you're careless with memory usage. In addition to the memory bus
bandwidth, concurrency is highly impacted by locality of reference.
Keeping the voracious cpus fed with useful work is quite challenging
for many pragmatic application tasks.
Makes me wonder why NSFetchRequest even supports a predicate, since
its predicate has all these limitations and is supposedly more
expensive when compared to fetching all objects and then using -
[NSArray filteredArrayWithPredicate:] ?
...
If you redrew the entire window all the time, for each and every pixel
change, and then marveled at the limitations, people might suggest
clipping your drawing to the intersection of the dirty and visible
regions. You might also use bounding rects as a convenient
approximation of more complex region clipping calculations.
These days even apps with modest requirements need bounding rects and
region clipping for their data too.
- Ben
_______________________________________________
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
