Re: Mapping multiple EOs to one table
Re: Mapping multiple EOs to one table
- Subject: Re: Mapping multiple EOs to one table
- From: Ricardo Strausz <email@hidden>
- Date: Mon, 18 Aug 2003 18:18:43 -0500
On lunes, agos 18, 2003, at 17:46 America/Mexico_City, Chuck Hill wrote:
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.
I wanted to say "the whole raw"...
This side effects shoud be included in "Disadventages" on page 132 of
Advanced Enterprise Object Modeling;
Thanks Chuck.
Ray: be carefull and try to prevent simultaneus "views" of the same
raw with different objects.
Yours,
Dino
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
Dino
http://homepage.mac.com/strausz
_______________________________________________
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.