Re: [REPOST] Data Modeler/Core Data
Re: [REPOST] Data Modeler/Core Data
- Subject: Re: [REPOST] Data Modeler/Core Data
- From: Andre <email@hidden>
- Date: Fri, 10 Feb 2006 16:32:52 -0800
On 平成 18/02/10, at 13:05, Cem Karan wrote:
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.
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....
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.
6) I noticed that CoreData can handle multiple threads
(although I haven't explored that aspect yet). Can it be
distributed? That is, if I create a cluster of machines, do I
end up with a bottleneck because the only way to distribute the
data is via NSProxy, or does CoreData have a truly intelligent
way of replicating data such that the whole cluster looks like
it has one large backing store? If it does have this ability,
what about security? That is, do I have to figure out how to
setup a VPN, use digital certificates, etc., or is there
something in CoreData that will take care of it for me?
So, coredata does not handle any of that AFAIK. This is really
Enterprise Objects territory. I think this stuff is also
"enhancement report" bound. I myself am hoping (and requesting
for) the very things you are looking for.
While Coredata is very powerful for how easy it is to use, there
are still some holes to be filled. I do really look forward to
Core Data 2.0!
Same here! I could really use the stuff in #6 because what I
want to write is a distributed simulator. Most of the time, a
node will be handling the data in its own cell (this is FEA
code), but it would need to be able to share the data at the
surfaces of a cell. I can also see uses for compile farms, and
anything else that XGrid is good for, but for it to work well,
you really need to be able to rely on the data being there even
when nodes fall off the network, and you need to know that only
authorized nodes are allowed to access the data (via certificates
probably...)
Yea, Enterprise Objects is more suited to what you want in terms
of #6. Have you toyed with an Enterprise Objects Cocoa App? The
APIs between it and Coredata are pretty similar, though EO has
more learning curve its more flexible. I don't think there are any
licenses anymore to distribute Cocoa EO apps, but Java and Web
Objects apps are supported.... I do wish they had just gave is EO
sometimes.... but Coredata is much easier to learn thats for sure.
Anyways..........
I haven't tried them because I thought that it was going away in
favor of CoreData, but that was just my gut feeling, so I'm likely
wrong. I'll take a look at them.
Well, Enterprise Objects is mature, robust and scalable. Who know why
they didn't use it, especially now that WO 5.3 is basically
free..........
Thanks,
Cem Karan
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