Jim,
<vendor>
I absolutely agree that doing "an exhaustive search [on] the BLOB address
field in the database" is a bad thing. That is NOT what a competent CMP
engine will do. Instead, it will extract the value(s) from the primary key
class, and do a search based on those values. So, for example, if your primary
key class were "String", it will do a search (hopefuly indexed) on a VARCHAR
column, which is the foriegn key column. If the primary key class were:
public AddressPK implements Serializable {
public String id;
<etc>
}
it will do a search on a NUMBER column corresponding to the foreign key.
This is obviously much preferred to doing a BLOB comparison, which is not
even be supported by some DBMSs.
</vendor>
-jkw
Jim Archer wrote:
>
> Hi again Jonathan...
>
> Thanks very much for the detailed reply. Its very interesting and helpful.
> Until now, I had been under the impression that remote references could not
> be used as CMP fields in EBs. I'm very glad you cleared that up. As you
> said, it would make much more sense (from a design perspecitve) for an EB
> to have a reference to the remote interface of another EB rather than the
> primary key of it.
>
> I'm going to look into using remote interface objects as the CMP fields
> instead of primary keys. As you say, this will probably result in a BLOB.
> Then when I do an ejbFindByAddress(addr) call, I guess I'll get a
> Collection of people, but as the result of an exhaustive search the BLOB
> address field in the database. That does not sound too promising...
>
> Jim
>
> --On Wednesday, May 31, 2000 1:05 PM -0700 "Jonathan K. Weedon"
> <[EMAIL PROTECTED]> wrote:
>
> > 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".
>
> ===========================================================================
> 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".
