Hi!
Sebastien Alborini wrote:
> > Well, truly, findByXX methods should still work *unless XX is a
> > dependent EJB* right? That is, User.findByName(String name) works if
> > "name" is a field that corresponds directly to a DB column, but not if
> > "name" is itself an EJB that gets stored in the DB as a handle.
> >
> > Aaron
> >
>
> Yes it does.
>
> If "name" is itself an EJB, it gets stored as a handle, and the findByXX
> compares the handle in the database with the handle of the finder
> argument. (technical reason: JDBCStoreEntityCommand and
> JDBCFindByCommand both use JDBCCommand.setParameter, which is where the
> conversion ejb->handle is coded).
Doesn't this
1) rely on the db to be able to compare binary objects in the first
place?
2) rely on the format of the handle not to change? (i.e. if we change
the way handles are serialized it will break)
> I've just tested this with:
> - SomeEntity has a cmp-field public OtherEntity otherEntity
> - automatically generated finder findByOtherEntity(OtherEntity oe)
> works.
What database? Hypersonic?
> The downside ist that the finder argument must be the referenced bean
> itself (OtherEntity oe), and not only its pk, which I agree is less user
> friendly.
Could also be seen as more user friendly really. Of course, if the old
code was reverted back to which used primary keys to do the comparison
we could support both...
> The only thing that doesn't work anymore:
> If SomeEntity has a reference to OtherEntity and OtherEntity has a
> complex PK, you cannot do a "defined finder" query for SomeEntity on
> only a part of the OtherEntity's PK.
Hm.. not with you.. "a part of".. how would that work in the first
place?
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
