The fact that you have found that quote in the book (even in the 2nd
edition) definately indicates that at least at some point in time it has not
been allowed to use primitive types as primary keys. Still, the
specification is under constant development, and it seems to me the subject
is deliberately ignored in the specification - in fact I did a search on
java.lang.Integer and java.lang.Long and there is _no_ example what so ever
which includes a primary key of neither the wrapper class nor the primitive
type - odd... Perhaps it is avoided in the specification because it is
subject to change.
Personally I would like to here it from "the horse's own mouth" aswell - to
be absolutely sure. We are definately not the only people who bumped into
this issue.
I am not sure your argument about EntityContext.getPrimaryKey() returning an
object can be used here, though. Since EntityContext is an interface which
is implemented by some proprietary class it is _possible_ that a container
could construct the Integer object for you no matter what kind of Integer
you are using. Please note the earlier post in this thread by Michael Third,
too. He states they are using long's - so it works. And why not? - You can
use any primitive type which is valid in RMI-IIOP, which for what I know
includes primitive types aswell.
Which brings me to my conclusion: Since this issue is unclear in the
specification there is no guarantee that using int or long will work on any
EJB Server. Therefore I will continue to use Integer to make sure my beans
are platform independent. I personally go for a container independant
system.
Randahl
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 1. marts 2001 12:12
To: Orion-Interest
Subject: RE: Database schema type mappings
It's at the bottom of page 159 of Richard Monson-Haefel's _Enterprise
Java Beans, 2nd Ed_: "Although primary keys can be primitive wrappers
(Integer, Double, Long, etc.), primary keys cannot be primitive types
(int, double, long, etc.)"
I wasn't able to locate an explicit statement in the spec in my quick
scan, but the spec always refers to the primary key as the "primary key
class" and the deployment descriptor element is "prim-key-class". This
is further reinforced by the comments in the DTD.
It makes sense, because EntityContext.getPrimaryKey() returns an Object.
Thus all PKs *must* be Objects.
About question #1: I doubt there is any explicit requirement in the
spec that Integers be converted to ints in the database. In fact, the
spec doesn't require a relational database; that's simply an
implementation detail. Still, I doubt you will find *any* appservers
which serialize Integer keys as blobs - although it would work, the
performance penalty would be severe.
Jeff
>-----Original Message-----
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:22 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Thanks for the reply Jeff. Know I have two replies: One saying
>primary keys
>can be primitive types and one that says they can't.
>I am really looking forward to hearing your arguments, gentlemen ;-)
>
>BTW, Jeff: Your answer to question number 1 - do you have that from the
>specification, or...
>
>Randahl
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
>Schnitzer
>Sent: 1. marts 2001 02:52
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>
>Yes. All the class representations of the primitive types should work
>that way.
>
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>
>No. Primary keys must be Objects. This makes sense because
>EntityContext.getPrimaryKey() returns an Object.
>
>Jeff
>
>
>
