On 12 Nov 2012, at 14:15, Joerg Simon 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
> contexts
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 iOS5.
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 wrote:
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 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
On Nov 11, 2012, at 23:16 , Hunter Hillegas 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 mailing list (Cocoa-dev@lis
On Nov 11, 2012, at 15:54 , Hunter Hillegas 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 6? I can't find spec
On Nov 11, 2012, at 15:54 , Hunter Hillegas 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.
Instead of using -pred
> 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
>> 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 u
On Nov 11, 2012, at 9:57 , Hunter Hillegas 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 a big batch update o
pens in memory
NSManagedObject *matchingObject = [[possibleEvents filteredArrayUsingPredicate:
indexMatchPredicate] lastObject];
Hunter
On Nov 11, 2012, at 6:42 AM, Rick Mann wrote:
> I'm seeing a substantial degradation in Core Data fetch performance after
> just a few thousand objects, in the
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
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 F
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 B
14 matches
Mail list logo
