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: Tue, 19 Aug 2003 20:06:18 -0700
Hi Ray,
At 02:25 PM 20/08/2003 +1200, Ray Ackland wrote:
>I realise your knowledge comes from having experienced the problems
>posed by EOModeler, where mine is mostly from a book. I also must admit
>that I am not as optimistic as I used to be about success. However this
>exercise is helping me learn a lot more about the hidden complexities
>and how I've only been reading about the iceberg's tip.
>
>Also as I feel the frustration of coming so close, I get a clearer
>picture of the smaller details. And I still get confused.
>
Well, it is not always a clear subject. Your not the only one who gets
confused now and again. :-)
>On one hand, I think that EO should not care that a database row is
>pretending to be several objects as EO is just getting data returned;
>
I think that is one flaw in your thinking. Although you are only
interested in the data as a read only view, EOF has no way of knowing that.
It is also not what it was built for so it doesn't even do that.
Regardless of what you are trying to do EOF needs to maintain a unique
connection between that row of data and the eo objects (one per ec) that
represent it. It also needs to maintain a unique identity of the row
(EOGlobalID) so that relationships from other eo objects to that eo object
are consistent adn can be persisted in the database.
>and I also start to see complications caused by trying to fool EO
>without fully understanding the fine print.
>
Trust me, EOF does *not* like being trifled with. Grin.
>In any case, I thank you for your comments. If I had thought of doing
>it as an inheritance hierarchy on my own, I would now be here asking
>why it wasn't working.
>
>/* several hours of trying things occurred here */
>
> From what I have experimented with so far, the results are interesting.
>It seems like it will work - as long as you are showing the same fields
>from the different entities. When I add another field (one which is in
>one entity, but not the other) sometimes it works and sometimes not (ie
>depending on which entity you add too, even though they are both
>children of the parent, and should be equals).
>
I suspect you are only using Key-Value Coding to access the data. That is
what makes it appear to be working OK (and appear is the correct word).
KVC is type agnostic. It does not care about the Java class of the object
it is getting data from, it just takes it by name. If you start working
with these objects in Java code you'll start seeing class cast exceptions.
>I am *starting* to understand now what Chuck was referring to about
>them being unique in an inheritance hierarchy. It works like EO brings
>in not one entity to represent the child, but rather the parent and
>child entities - each one holding its part of the data. This is where
>complication occurs as the globalIDs conflict because it is based on a
>PK and the entity type and ....
>
Yes. For inheritance the EOGlobalID is a combination of the PK and the
*parent* entity.
>Well, I am still trying to figure these things out. But thank guys for
>your support and guidance. I could have taken your advice to start
>with, but I'm glad I have given things a go for myself.
>
I think it is a good way to learn. You cover a lot more ground and
remember the lessons better.
Chuck
>On Tuesday, Aug 19, 2003, at 12:48 Pacific/Auckland, Chuck Hill wrote:
>
>> They are also unique (must be!) within an inheritance hierarchy based
>> on
>> the root Entity. Go ahead, try it!
>>
>> Don't put too much faith in the accuracy of the finer details of those
>> docs. That's a mid-level overview. There is more that is not
>> documented
>> than there is.
>>
>>
>> Chuck
>
>
>On Wednesday, Aug 20, 2003, at 04:19 Pacific/Auckland, Jonathan
>Rochkind wrote:
>
>> I guess the only way to know is to try it out. My experience with EOF
>> leads me to be very cautious for the same reasons Chuck is. I'd be
>> willing to bet that it won't work, if the goal is what I think it is.
>> But apparently Chuck and my arguments have been unconvincing to
>> others. :) So, sure, try it out. If it works, be sure to let us know;
>> that's be great.
>>
>> --Jonathan
>_______________________________________________
>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
_______________________________________________
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.