Jim,
<vendor>
This is a very interesting question, which shines a light into some of
the darker corners of the EJB specification, corners which some vendor
may prefer you not look into ;-)
Basically, if your question is: "is this behavior required by the EJB
1.1 specification?" then the answer is yes.
However, if you question is: "is this behavior supported by all
AppServer which claim to support EJB 1.1" then the answer, sadly, is
no.
If we look at the EJB 1.1 spec, it places the following requirement
on a CMP entity bean (Section 9.4.1):
"The Bean Provider must ensure that the Java programming language
types assigned to the container-managed fields are restricted to the
following: Java programming language primitives types, Java
programming language serializable types, and references to enterprise
beans' remote or home interfaces.
"The Container Provider may, but is not required to, use Java
programming language Serialization to store the container-managed
fields in the database. If the Container chooses a different
approach, the effect should be equivalant to that of Java programming
language Serialization. The Container must also be capable of
persisting references to enterprise beans' remote and home interfaces
(for example, by storing their handle or primary key)."
Thus, it is legal to have as a container-managed field either a
primary key (because it must be Serializable, per the spec.) or remote
reference (which is explicitly required to be supported). Note that
many of the AppServers on the market completely ignore these
requirements.
Although it is nowhere stated, it seems eminently reasonable that a
finder method be able to use any container-managed field as a
parameter in a query. For example, if my bean has a container-managed
field of type String called "firstName", then I should be able to have
a finder method such as:
public Collection findByFirstName(String firstName) ...;
Likewise, if my bean has a container-managed field of type AddressPK
(which is Serializable, so the spec requires it be supported), then I
should be able to have a finder method such as:
public Collection findByAddress(AddressPK addressPK) ...;
And finally, if my bean has a container-managed field of type Address
(which is a remote reference, so the spec requires it be supported),
then I should be able to have a finder method such as:
public Collection findByAddress(Address address) ...;
So, I believe it is clear that the EJB 1.1 spec covers this. However,
as I said previously, many of the AppServers on the market which claim
EJB 1.1 compliance do not support this. Obviously, IAS does.
One last point. The EJB spec points out that storing things like
primary keys or remote object references using Serialization is not
required. In fact, neither is it at all desirable, since in the
database these references typically correspond to foreign keys, which
are typically of type NUMBER or VARCHAR, not BLOB. IAS provides the
ability to map either primary key instances or remote object
references directly to database-level foreign keys. So, if your primary
key were:
public AddressPK implements Serializable {
public String id;
<etc>
}
Then we would store this in a NUMBER foreign key in the database, not
as a BLOB.
Likewise, in finder methods, we don't do a SQL select using the
Serialized primary key (or object reference) but rather by using
underlying primary key value (i.e., "id", above), which is much more
efficient and reasonable, from a database perspective.
</vendor>
-jkw
Jim Archer wrote:
>
> Thanks, Jonathan...
>
> Does this imply that this ability is not something covered by the 1.1 spec?
> Its important for my project that I be able to deploy in any 1.1 compliant
> server, so I have to keep what I do to things mandated by the spec.
>
> If its not in the spec, whats the recomended procedure for handling
> something like this? You suggested passing the address down, which I agree
> is a nices solution, but how would I make it work at deployment time?
>
> Thanks!
>
> Jim
>
> --On Wednesday, May 31, 2000 10:33 AM -0700 "Jonathan K. Weedon"
> <[EMAIL PROTECTED]> wrote:
>
> > Jim,
> >
> > <vendor>
> >
> > IAS 4 provides the ability to use primary keys as parameters
> > to finder method.
> >
> > Alternatively, you could have the finder method take the
> > Address remote references as a parameter:
> >
> > public Collection findByAddress(Address a) ...;
> >
> > which seems a little more object-oriented, to me, instead
> > of dealing always with primary keys.
> >
> > See our example:
> >
> > <ias>/examples/ejb/pigs
> >
> > for details.
> >
> > </vendor>
> >
> > -jkw
> >
> > Jim Archer wrote:
> >>
> >> Hi All...
> >>
> >> I'm wondering if it is possible to have a finder method that accepts as a
> >> parameter the primary key object of another EB.
> >>
> >> For example, I might have a PersonEB entity bean that has a reference to
> >> an AddressEB entity bean. The AddressEB would have its own primary key
> >> class, AddressPK. The Person bean might have a finder method like this:
> >>
> >> public Collection findByAddress(AddressPK adr) throws FinderException,
> >> RemoteException;
> >>
> >> Of course, the idea is to use CMP to persist all the Person beans and all
> >> the Address beans and to not replicate addresses in the database
> >> unnecesserally. Five people with the same address would each have a
> >> reference to the same Address bean. This is a contrived example. My
> >> actual project will win big doing this type of thing.
> >>
> >> It seems easy enough to code the method, of course, but how does it get
> >> deployed? Is this doable?
> >>
> >> Thanks!
> >>
> >> Jim
===========================================================================
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".
