Am Do,02.10.2008 um 00:16 schrieb Jerry Krinock:
On 2008 Sep, 30, at 10:58, I. Savant wrote:
The 'correct' approach depends entirely on the model.
Yes, I appreciated Amin's thoughts but didn't have much to add. An
important step in modelling is to draw a potato around the part of
the
Am Di,30.09.2008 um 19:58 schrieb I. Savant:
On Mon, Sep 29, 2008 at 3:03 AM, Negm-Awad Amin <[EMAIL PROTECTED]
> wrote:
But now I find there is an even more natural way, which is to just
leave
them as a set or array, and store in an attribute of type
Transformable.
The default transforme
On 2008 Sep, 30, at 10:58, I. Savant wrote:
The 'correct' approach depends entirely on the model.
Yes, I appreciated Amin's thoughts but didn't have much to add. An
important step in modelling is to draw a potato around the part of the
world that you're going to include. You have to mak
On Mon, Sep 29, 2008 at 3:03 AM, Negm-Awad Amin <[EMAIL PROTECTED]> wrote:
>> But now I find there is an even more natural way, which is to just leave
>> them as a set or array, and store in an attribute of type Transformable.
>> The default transformer en/decodes the collection into/from an NSDa
On 2008 Sep, 25, at 18:08, Jerry Krinock wrote:
I'm surprised that I've never seen this discussed or documented. Is
this going to get me into any trouble?
Conclusion
So far I haven't seen any trouble, but some quick tests indicate that
when subsequently invoking -[NSManagedObjectContext
Am Fr,26.09.2008 um 03:08 schrieb Jerry Krinock:
When I first looked at Core Data, I saw that there was no such
attribute type as "Array" or "Set", and concluded that collections
must be modelled as relationships. This would be overkill in many
cases, for example, in a Person type of appl
When I first looked at Core Data, I saw that there was no such
attribute type as "Array" or "Set", and concluded that collections
must be modelled as relationships. This would be overkill in many
cases, for example, in a Person type of application if you wanted to
list the names of each Pe