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 14:57:38 -0500
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.
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.
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).
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.
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...)
As I said before, I'll file enhancement requests.
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