Re: [REPOST] Data Modeler/Core Data
Re: [REPOST] Data Modeler/Core Data
- Subject: Re: [REPOST] Data Modeler/Core Data
- From: Andre <email@hidden>
- Date: Wed, 15 Feb 2006 14:29:16 -0800
Cem Karan wrote:
Either apple's documentation is not clear (setSubentites really
only is to set the name) or its a bug IMO. If it does set it's
name only, how useful is that?
My "workaround" was to do a category on NSEntityDescription
overriding the method in question, and propagating the properties
manually.
OK, thank you for the heads up on that one. I'll keep it in mind
as I go along.
Yea, I just got a correspondence about this from ADC, and its a
"known issue" so they seem know about it.
The only downside is that if both a and b have a value, only a is
returned, so you have some problems, but you can account for this
in the core data validation methods, and check for example if
("a" != nil and "b" != nill) then you accept "c."
Sorry for the confusing post! Hope I communicated well enough....
Don't worry, it isn't confusing! The problem with multiple
inheritance in this manner is that somehow we need to know which
parent is the current effective parent (because otherwise you don't
have a C union, you have a C struct). I think what may have to
happen is that either I programmatically create a new object based
on NSManagedObject that is a union, or that CoreData needs to be
extended to encompass the concept of a C union.
Yea, I don't really think Coredata is very happy with "chameleon"
entities that can be one or the other unless they are part of a
hierarchy....
I think core data needs to be enhanced for this functionality, its
not going to be too easy in any case currently.... to get a full
union style behavior.
So I think its safe to assume a collection of 4BN is plausible,
though you'd probably run out of RAM first.... when 64-bit cocoa
comes out, you can check the docs and do an #ifdef in case they
add a method that returns long instead of unsigned...... I suppose.
Yes, I can see what you're saying. My hope was to avoid having
different binaries. I think I can solve it via your solution, and
abstracting much of the work into multiple frameworks though...
Hopefully apple will have a very clean solution to Cocoa/64 but it
will probably have to be a hands-on approach for us to take
advantage of it......
Good luck.
Andre
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden