Re: [REPOST] Data Modeler/Core Data
Re: [REPOST] Data Modeler/Core Data
- Subject: Re: [REPOST] Data Modeler/Core Data
- From: Cem Karan <email@hidden>
- Date: Mon, 13 Feb 2006 08:59:31 -0500
I see, yea, currently things are pretty limited, I've toyed with
the idea of making my own modeler app, but then I ran into the
setSubentities: bug....
What is that bug?
[NSEntityDescription setSubentities:] is supposed to set an array
of entities to become "sub entities" of the receiver. So, like in
the Xcode modeler, you create an abstract entity, set some shared
relationships, and attributes, then create a concrete entity(s)
that derive from that super-entity. The problem is, doing this in
code, simply sets the name of the super entity for the entities
that are becoming "sub entities."
So as a simple example, if I create an entity called
"AbstractModel" wiith attributes, eyeColor, hairColor, and IQ, and
I make a concerete entity that should derive from that abstract
entity, using [AbstractSuperModel setSubEntities:[NSArray
arrayWithObject: SuperModel]] SuperModel entity does not,
apparently, inherit the attributes of AbstractSuperModel..... I've
tried many different work arounds, even saving the model to a file
(made in code), importing it into XCode Modeler (which does show
the relationships as correct), recompiling the model after
importing in another empty app, and running it, to my dismay, the
properties were not inherited.
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.
4) The only way I've been able to think of for specifying
enumerations is to have an abstract entity that all of the
concrete entities declare as their parent; entities that need
to use the enumeration specify that they expect an entity of
the abstract type. Is this the best way of doing things in
the modeler?
Can you give an example what you mean by enumerator? I'm not
sure I understand...
Maybe I should have said a union rather than an enumeration:
basically, I would like to be able to directly model something
like the following:
struct foo {
enum type;
union object {
struct {
char bee;
int hello;
} a;
struct {
uint64_t baz;
} b;
struct {
double betty;
} c;
};
};
(Directly typed into Mail, there are probably some bugs in there)
Currently, my solution to this problem is to make 'object' an
abstract type. 'a', 'b', and 'c' all derive from 'object'.
Depending on the value stored in 'type', I select which concrete
type 'object' really is. The problem with this solution is that
I have to remember what enum value goes with which type. I
would rather be able to create a fetch request which could tell
me the type stored in object, or, better yet, if I go to fetch
the object, CoreData automagically returns the object that is
currently stored there (since it would have to store all the
type information in the data store anyways in order to work right).
Perhaps multiple inheritance? In terms of GUI stuff I think MO is
maybe not good, but for data modeling, I think Multiple
Inheritance may be a very very powerful thing...
I have thought about that myself, and wanted on multiple
occasions to do what you describe. My thought was: multiple
inheritance.
When I think of multiple inheritance, I think of an object with
multiple parents; is that what you're saying? If so, how would it
help?
I mean in the sense of entity descriptions, a single entity could
inherit from multiple parent entities.
Well, maybe I'm misinterpreting, but for your union above, you
would have:
struct {
char bee;
int hello;
} a;
and
struct {
uint64_t baz;
} b;
and
struct {
double betty;
} c;
In my idea, if there were a single entity "foo" who derived from
entities a, b, and c, when you want to pull and specific value type
of either a b or c, then since the abstract class is compatible
with any of a b or c entities, when any request fetches say want
only a, foo would get returned, but you could check if (foo.a ==
nil) or (foo.b==nill) and if so, the ones with no value in member a
would not get returned from the fetch. Or, since explicitly calling
a fetch for a, the runtime would only would want "a" returned, then
core data could simply use its proxy object magic and hide the foo
object and wrap any calls to set or get only to the variables known
in "a..." is that what your looking for? Maybe I misinterpreted?
Because making a union of a b an c means that foo sort of 'is' a b
and c right? IOW, the first item you set the value to foo.a or
foo.b or foo.c thats the "type" it becomes. If foo.a and foo.b
became nil and foo.c wasn't, then its type would be c and calls to
return c would return foo. JMHO, maybe MO can help, maybe not....
-------------------
I'm thinking maybe, what you an do now with the current core data
is this: make foo an entity. Make a b and c entities with the
properties you want. Then in foo, make to-one relations to a b and c.
Now, in any fetch, if a or b or c is not present, you can check for
this. So if [foo valueForKey:@"a"] returns nil, then you can assume
its not a. In code, further more, if
[foo valueForKey:@"a"] returns not-nil, then you can have method on
foo that returns the "kind" like so:
- (NSString *)instanceType
{
BOOL isA = ([self valueForKey:@"a"] ? YES : NO);
BOOL isB = ([self valueForKey:@"b"] ? YES : NO);
BOOL isC = ([self valueForKey:@"c"] ? YES : NO);
//You want only a single type at a time
if (isA)
return @"a";
if (isB)
return @"b";
if (isC)
return @"c";
}
- (id)instanceValue
{
//You want only a single type at a time
if ([self valueForKey:@"a"])
return [self valueForKey:@"a"];
if ([self valueForKey:@"b"])
return [self valueForKey:@"b"];
if ([self valueForKey:@"c"] )
return [self valueForKey:@"c"] ;
return nil;
}
So in an implementation, you could have a fetch tequest for object
foo and depending on the type you want, set the predicate to want
instanceType == "c" or b or a etc.
In you bindings, any objects that want a "c" value, after your
fetch returns all the foo objects that have a "c" member, in the UI
you bind to foo.instanceType for the arrangedObjects, and
foo.instanceType.betty for value bindings etc.
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.
5) What is the upper limit to the number of elements that an
element can own? I.e., when I specify a 'to-many'
relationship, at what point will CoreData break when I add one
more element? What is the upper limit on the size of the
store? I'm being deliberately vague in that I don't want to
find that the SQL store can handle huge amounts of data, but
that the binary or XML versions can't.
I would think that uint_32 would be the upper limit until
everything is 64-bit. Though I may be mistaken.
Ah, too bad... do you know if there is a way of dynamically
discovering this information? I can write my code in such a way
as to break up my data among different data stores, which might
alleviate this problem, but I can't really reduce the overall
amount of data I'm going to end up storing.
Coredata makes use of the objective-c runtime, and basically runs
on Key-Value Coding and Key-Value Binding, so its limited to
whatever, as Matthew said, is supported by objective-c. Which I'm
assuming is Unsigned Integer (currently 32-bit). SQL-lite is just
a back-end, so that itself may be capable of more or not, I don't
know, but wouldn't make much difference I'm guessing to core data
right now.
Too bad; it would be useful to know the info dynamically, so that
I can avoid breaking up data into multiple stores on 64 bit
machines, but do so on 32 bit machines. Otherwise, I'm going to
have to assume the lowest common denominator... :-/
Well, maybe not. In the docs for Key-Value Coding, to return a
count of items in a to-many, you return an unsigned int like so: -
(unsigned int)countOfTransactions.
And NSArray/NSSet that both are used to contain to-many relations
for KVC and Core Data return unsigned for their count methods: -
(unsigned)count
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...
Thanks,
Cem Karan
_______________________________________________
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