That's better, but it amounts to tricking the container to do what I want.
A better solution would be to be able to link relationships to finders, so
executing a finder would also find/load the beans on "the other side" of the
relationship. No session bean hacks required.
- Avi
--
And now for something completely different.
> -----Original Message-----
> From: William Louth [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 17, 2001 23:36
> To: [EMAIL PROTECTED]
> Subject: Re: CMP relationships in EJB2.0
>
>
> Hi,
>
> I can reduce the number down to 2. By first getting a session
> bean to call
> on the ahome.findWherePropertyGreaterThan(int value) and
> retrieving the
> beans (load-state=true) that have property > 7. Then the same
> session bean
> loops through and gets the list of ids and puts them into an
> array and then
> calls bhome.findByPrimaryKeys(int[]) with the array just created. The
> Borlands Appserver 4.5 cmp engine supports the use of arrays
> in finders and
> will construct an SQL IN clause with each array element. The
> problem with
> this is that my direction of access will be reversed. I will
> move from bBean
> to aBean (m->1). This movement won't result in a sql call
> since the list of
> abeans have been previously loaded by my first find call - it
> will be loaded
> from the entity cache.
>
> William Louth
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Avi Kivity
> Sent: Thursday, May 17, 2001 6:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CMP relationships in EJB2.0
>
>
> > >
> > > aHome.findBySomeProprety(7) ->
> > >
> > > select a.id, a.property
> > > from a
> > > where a.property > 7
> > >
> > > and then:
> > >
> > > select b.id, b.someotherfield, b.aref
> > > from a, b
> > > where a.id=b.aref
> > > and a.property > 7
> > >
> > > (This would be the equivalent of a join. Alternatively, I
> > > wouldn't much mind if the container requested a single SQL
> > with the join)
> >
> > Well, it seems to me this example is way too specific to be
> > handled through
> > CMP. You would need to go with BMP for that. Note that you
> > could actually
> > use both, and leverage underlying CMR relationships to
> > perform some of those
> > queries for you. But for the final result, you would
> > definitely need to
> > write some code by hand.
>
> I don't think this example is specific. For example, a users/groups
> relationship is very similar - you want to display a table
> with the user
> name and group name. Using finders-call-ejbload (or an
> equivalent), you get
> the users in one shot. But then N selects are required for
> the groups (lets
> assume a great number so caching is ineffective). The example
> also applies
> to order line item/product name, or anywhere else a join
> would be used.
> Possibly every nontrival table display requires a join.
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
