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 12:55:31 -0800
On 平成 18/02/10, at 11:57, Cem Karan wrote:
Thank you for your comments Andre, as you suggest, I will file bug
reports on all these.
Apologies to those who saw this before and decided to ignore it;
I never got any comments earlier, and was hoping to get some...
I've been fiddling with the Data Modeler in XCode 2.2.1, and I've
run into these problems and wanted to get other's comments on them.
1) When I specify an Integer 64 as an attribute, and try to set
its max/min/default values to anything outside what an Integer 32
can hold, the modeler automatically clamps down to the range
[-2**32, 2**32). This is a bug, and I need to file it (or so I
think). Comments?
Perhaps just leaving it blank for the max integer would suffice,
since of course it wouldn't be able to go any higher at runtime
anyways.
That would work if you really plan on using the full range of an
Integer 64, but what if you need something like [-2**35, 2**36]?
That is the bug that I see.
Yea, then there is no workaround.
2) I have yet to find a way to group parts of the graph together;
that is, my graph is getting VERY crowded, and it would be nice
to abstract a subset of the model in a group, just so I can see
the forest and the trees at the same time.
Yes, this is a mis-feature IMO. Please file a bug. I have filed
one on this. And actually, it goes a little deeper because what
happening is that even in-code data models cant link two entities
properly via sub-super entities. IOW, if you have two models (as I
have) and want to link them together by specifying a parent
entity, it can't work because parent properties are not
propagated. If you simply want to break the view up though, not
link them as sub entity, I would suggest still to file an
enhancement report.
As an aside, it may be a good idea if your model is getting very
complicated to re-think it and pare it down to be more manageable.
I'm not saying I know your requirements, so pelase forgive me if
I'm out of place. One thing I did was create a single entity, then
a "type" entity that is a to-one. So instead of having say, an
employee entity, a supervisor entity, an a manager entity, just
one "employee" entity, and thier "type" designates their role.
I've been able to pare down my models by 70% using this technique
and also inheritance. If the model is too complicated, its gonna
hurt down the line and also complicates backward compatibility...
JMHO.
You're right of course, but what I was trying to do was to push the
limits of what CoreData and the modeler can handle. My test case
was to try to code the entire EBNF syntax of VHDL using the
modeler, which is something it most definitely wasn't designed to
do, but if you do have a truly complicated data model, then these
are important questions.
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....
3) Is it possible to create limits within the model based on
other items within the model? E.g., I have two attributes,
minNumItems and maxNumItems. I want to be able to specify that
maxNumItems >= minNumItems within the model. I know that I can
write code that will do this, I was just wondering if it is
possible to do within the modeler.
I don't think so. I plan to file an enhancement request for this
as well. Please also file an enhancement request.
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.
Finally, I have a couple of questions that would probably be
better answered on the Cocoa-dev list, but I'd rather not split
this post up.
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.
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..........
Good luck.
Andre
As I said before, I'll file enhancement requests.
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