On Jul 19, 2009, at 5:05 PM, mmalc Crawford wrote:
The fundamental behaviour is that method returns NO if something
goes wrong.
As Jerry kindly pointed out off-list, this method of course returns
nil -- not NO -- if something goes wrong. The important issue (and
one which has given rise
On Jul 19, 2009, at 1:59 PM, Squ Aire wrote:
* Finally an unrelated and basic Core Data question: Where do you
paste the code you copy using the "Copy Method Declarations/
Implementations" feature in the data modeling tool? I really want to
use those things because it is, according to docs,
On Jul 19, 2009, at 3:15 PM, Jerry Krinock wrote:
The case in point here is that -[NSManagedObjectContext
executeFetchRequest:error:] returns an NSError if something goes
wrong.
This is misleading.
The fundamental behaviour is that method returns NO if something goes
wrong. In addition
On 2009 Jul 19, at 13:59, Squ Aire wrote:
Thanks for these wonderful answer and tips.
I like how you have designed this stuff. Gladly, it is similar to
what I've been doing. Based on this I can now refine my own stuff,
e.g. by doing a subclass for each entity like you are doing.
Don't ge
om
> Date: Sat, 18 Jul 2009 22:43:59 -0700
> Subject: Re: Core Data design patterns
>
>
> On 2009 Jul 17, at 09:26, Squ Aire wrote:
>
>> Throughout my application I have to do fetching. I have simplified
>> my code by making a helper class called CoreDataHelper...
>
On 2009 Jul 17, at 09:26, Squ Aire wrote:
Throughout my application I have to do fetching. I have simplified
my code by making a helper class called CoreDataHelper...
In fact, I can think of another variation of my method. Namely, to
not have class methods in CoreDataHelper, but rather ins
Let's say I have the usual Employee and Department entities.
Throughout my application I have to do fetching. I have simplified my code by
making a helper class called CoreDataHelper, which has all kinds different
helper methods, such as
+(NSArray *)employeesInDepartment:(NSManagedObject*)dep
