marc fleury wrote:
> OK I will do it one last time:
>
> The previous stuff DID NOT OFFER ME NAVIGATION EITHER.
1. If a bean X had a field Foo pointing to bean Y it was properly stored
so that you could do getFoo() and setFoo().
2. If a bean X had a field Foo pointing to bean Y one could find X's
with Foo set to Y by calling findByFoo(Y)
In your opinion, why does this not count as proper navigation?
This is what *used* to work, and 2 doesn't anymore. What's the gain? I
just don't see it.
> So I have to go in
> the jaws CMP stuff to make it all managed and it doesn't buy me anything
> (except find by on the fields of the PK, woohoo!)...
The finds were really nice IMHO, but one other thing is that the beans
were more loosely coupled. You said that handles do not store where they
were loaded from? So, this means that if a bean X stores a reference Foo
to bean Y, and Y is in another server, then this reference will break
upon load since it will try to find Y in X's server (where it is not
available).
And, if we change the handle to indeed include the servers name then it
will be fragile too since if Y moves to another server the reference
does not work. With a primary key reference one simply uses the defined
EJB-ref (which always points to the correct server) and it just works.
Handles are not meant to support entity bean references. IMHO they were
introduced to allow serilization of stateful session beans, and since
stateful session beans have a fairly short life-span they're not as
sensitive to these kinds of changes to the system configuration.
> this one doesn't offer
> navigation either
And the previous one did... so, what are you shouting about? What is the
big win?
> but at least is simple and works (don't have to retrieve
> the pk everywhere in the code.
When you say "everywhere in the code" you are talking about JAWS, right?
And I think there is a limited number of places where this is done, and
the code was already written. So, WAYTA? (What Are You Talking About)
> I am looking forward to a REAL solution to
> this problem (building real queries on dependent stuff ala 2.0) not a series
> of hacks we fight over...
IMHO the previous solution was clean, elegant, and working. At least for
single references, collections is a different deal, which you are
correct about.
> One thing is for sure: the only thing I care about is the metadata, the rest
> I just want functionality for storing collections, any object and minimal
> intervention of storing ejb-ref, the more automated the better (btw, as long
> as we automate the detection of ejb-ref, pk or handle is equivalent to me
> (since neither offer navigation))
Again, please define "navigation" and how the previous solution did not
offer this.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
