Re: Mapping multiple EOs to one table
Re: Mapping multiple EOs to one table
- Subject: Re: Mapping multiple EOs to one table
- From: Chuck Hill <email@hidden>
- Date: Mon, 18 Aug 2003 15:46:27 -0700
- Organization: Global Village Consulting, Inc.
Ricardo Strausz wrote:
What is the scope of an EOGlobalID??
That depends. :-) In theory it is global. In practice, out of the
box it is limited to one instance.
Isn't the application?
Not if you are using one of the distributed change notification
frameworks.
If so, two concurrent users, with different app id, will have not problem.
Yes, assuming you can guarantee the one instance will never fetch both
"views" of the object.
Supposing this is correct, the problem may ocure with a single user (in
a single app) tring to see the hole row, but from different scenarios...
is it?
Anything that causes both views to be fetches may result in confusion
in your code.
But then, the logic most prevent him to use a "bigger" scenario in which
s.he can see the hole object (and do a fetch ---or refault---) from the
parent entity...
There is no whole or partial object. There are different objects that
you are trying to consider as one and which EOF can not accurately
tell apart. You can have the ec forgetObject() and refetch it, but
this may have unintended side effects.
Chuck
Am I loosing something?
Dino
On lunes, agos 18, 2003, at 17:11 America/Mexico_City, Chuck Hill wrote:
When EOF fetches an object it associates the snapshot with the entity
type through the EOGlobalID. If you fetch a row from that table
containing the same PK then EOF will not change its mind about what
class it is. So you could do a fetch for EntityA but get instances of
EntityB returned instead. That is why you don't want to do this.
Don't treat entities as database views.
Chuck
Ricardo Strausz wrote:
On lunes, agos 18, 2003, at 16:10 America/Mexico_City, Jonathan
Rochkind wrote:
I'm doubtful that single table inheritance will work for you. The
EOF inheritance scheme assumes that each row represents a certain
class, and doesn't change back and forth. You have rows that really
are all classes at once, it's not that certain rows are certain
classes. It's that they're all at once, but you just don't want to
fetch all the data in at once. I don't think you are going to be
able to use EOF inheritance in a way that achieves your goals
(doesn't fetch in all columns at once), but doesn't cause any
problems. That's too far from what it's intended for, I think.
I do not undestud your concern...
Say I have a table with four columns: PK, date, anInt & aFloat
and I want to see it in two different scenarios: in the first only
PK, date & anInt, and in the second PK, date & aFloat.
I can make a parent entity with PK & date and two childs (each with
the extra column added as an atribute), all mapped to the same table...
I think that the only thing to be cocerned here is to alow those
extra atributes to be NULL in the database...
Dino
But I haven't been able to think of a better solution either. You
might be best off just moving your data to a number of different
tables, instead of having them all in one table.
With your previous design, having multiple EOEntities that are
really the same table, you could try something like: Designate of
your entities as the 'primary' one. Only this one will ever be
inserted. It has relationships to the other entities, that are
really relationships to other 'parts' of the same row the source EO
represents. Follow these relationships to get these other parts;
don't ever insert EOs of these other entities. Still not sure that
will work. Monkeying around with the 'propagate primary key' and
'mandatory' and 'owns destination' attributes on the relationships
from this 'main' entity to the other ones might get you somewhere
too. But I'm not too optimistic about it myself.
--Jonathan
At 08:23 AM 8/19/2003 +1200, Ray Ackland wrote:
Well, even though many of the tables will only be sharing one
common field (primary key) I guess what we are looking at is really
single table inheritance. This could be the way to go. Seems to
meet all the criteria - the parent class is just the primary key
field.
I will definitely try it and tell you what happens. That gives me
much more optimism.
Ray.
On Tuesday, Aug 19, 2003, at 06:08 Pacific/Auckland, Ricardo
Strausz wrote:
Just guessing...
but first, does you multiple views of the same table inherits from
one the other?
It may be that, if you want to have different views from the same
table, define different childs for it (and not simply unrelated
entities which may confuse EOM).
Hope it helps! let us know
Dino
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.