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: Fri, 10 Feb 2006 16:05:37 -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?
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?
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... :-/
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.
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