On 12 Nov 2012, at 14:15, Joerg Simon j_si...@mac.com wrote:
This summs it up really nicely:
http://wbyoung.tumblr.com/post/27851725562/core-data-growing-pains
Links to radar bug reports are within the blog post.
The conclusion it is not usable does not hold under iOS6, since nested
Hi Hunter,
I am very interested in what bugs they fixed. Could you please share more
about it , e.g. an official bug fix report ?
Thanks
Bob
The API changes came in iOS 5 but in iOS 6 they fixed enough bugs to make it
work right. :-)
On Nov 11, 2012, at 4:50 PM, Rick Mann
This summs it up really nicely:
http://wbyoung.tumblr.com/post/27851725562/core-data-growing-pains
Links to radar bug reports are within the blog post.
The conclusion it is not usable does not hold under iOS6, since nested contexts
work quite wonderfully there, but it shows problems under
I'm seeing a substantial degradation in Core Data fetch performance after just
a few thousand objects, in the simulator on a beefy MacBook Pro.
My app loads data from the web, then uses an integer key in each downloaded
record to find the local record in Core Data. So I do a lot of queries like
= [[possibleEvents filteredArrayUsingPredicate:
indexMatchPredicate] lastObject];
Hunter
On Nov 11, 2012, at 6:42 AM, Rick Mann rm...@latencyzero.com wrote:
I'm seeing a substantial degradation in Core Data fetch performance after
just a few thousand objects, in the simulator on a beefy MacBook
On Nov 11, 2012, at 9:57 , Hunter Hillegas li...@lastonepicked.com wrote:
Do you have keyShadow set as indexed in the model? If not, you probably want
to give that a try.
Yeah, the key is indexed (as I pointed out in the original post :-))
If you have all of the keys up front (i.e. this is
Do you have keyShadow set as indexed in the model? If not, you probably want
to give that a try.
Yeah, the key is indexed (as I pointed out in the original post :-))
Heh, I re-read your post like four times and only just now saw that notation.
Whoops.
If you have all of the keys up front
I do. I was thinking about this last night. I'm concerned that this may
require too much memory, and building a string of 6400 IDs for the query to
then format...sounds expensive. Can one build IN queries directly?
I should note, I've done this quite successfully with workloads in the ~500
On Nov 11, 2012, at 15:54 , Hunter Hillegas li...@lastonepicked.com wrote:
Heh, I re-read your post like four times and only just now saw that notation.
Whoops.
It happens.
Can one build IN queries directly?
I'm not entirely sure I know what you mean by 'directly' in this context.
On Nov 11, 2012, at 15:54 , Hunter Hillegas li...@lastonepicked.com wrote:
GCD, along with the Core Data changes in iOS 5 and 6 for handling
concurrency, make this much easier than it used to be (or at least cleaner
and harder to screw up as badly).
By the way, what were the changes in iOS
On Nov 11, 2012, at 23:16 , Hunter Hillegas li...@lastonepicked.com wrote:
The API changes came in iOS 5 but in iOS 6 they fixed enough bugs to make it
work right. :-)
Hrm, does that mean it won't work on iOS 5.1?
--
Rick
___
Cocoa-dev
The API changes came in iOS 5 but in iOS 6 they fixed enough bugs to make it
work right. :-)
On Nov 11, 2012, at 4:50 PM, Rick Mann rm...@latencyzero.com wrote:
GCD, along with the Core Data changes in iOS 5 and 6 for handling
concurrency, make this much easier than it used to be (or at
Hi all,
I have 2 CoreData entities, Foo and Bar. Both have 'name' string
attributes. There are textfields allowing the user to rename any Foo
and any Bar. Assume no 2 Foos can have the same name; likewise for
Bars. There is a relationship between Foo and Bar. I want a Foo to be
related to a
On Sep 2, 2010, at 14:46, Sean McBride wrote:
I have 2 CoreData entities, Foo and Bar. Both have 'name' string
attributes. There are textfields allowing the user to rename any Foo
and any Bar. Assume no 2 Foos can have the same name; likewise for
Bars. There is a relationship between Foo
14 matches
Mail list logo
