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".
