RE: Database schema type mappings
Jeff, about the bug you mention... that sounds very strange to me and it sure should not have anything to do with byte size, I think. The value millisInMonth easily fits into a long... So if you have a long representing the current time milliseconds and subtract one month of milliseconds, yes, that should definately produce a time last month. I would like to know if I am wrong in this assumption or what the bug REALLY was about (?) R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: 1. marts 2001 02:38 To: Orion-Interest Subject: RE: Database schema type mappings You're thinking C++. In Java: A long is 8 bytes, always. An int is 4 bytes, always. The byte-orders are fixed independent of the hardware, too. Speaking of byte size, here's something I found amusing (and annoying): long millisInMonth = 1000 * 60 * 60 * 24 * 30; Date thirtyDaysAgo = new Date(); thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth); This actually produces a date in the FUTURE! It took me a while to hunt down this bug because it had really wierd effects on my application. Jeff -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 11:02 AM To: Orion-Interest Subject: RE: Database schema type mappings Randahl, We use the primitive long for all of our primary keys for a couple of reasons: * primary keys can't be null so there isn't a need for Long (or Integer) * long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which is currently not a problem but could be when Itanium platforms come out. int's depend on the CPU's native integer type which happens to be 32bits on ix86 architectures. Michael Third Chief Software Architect parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, February 28, 2001 10:02 AM To: Orion-Interest Subject: Database schema type mappings If you look at the database schema in "orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping between the primitive java type "int" and the corresponding database type "int": type-mapping type="int" name="int" /. In my EJBs my primary keys and other attributes are of type Integer. Since there is no mapping for class Integer one could think that Integers would be mapped to VARBINARY. Luckily my integers are mapped to the database type "int", but this makes me ask two questions: 1. Why is Integers automatically converted to int by Orion - and is this a standard EJB convention? 2. Would it be legal to have a primary key of the primitive type "int" instead of Integer? Yours Randahl
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
RE: Database schema type mappings
Yes, it fits into a long, but by default constants like 1000 * 60 * 60 * 24 * 30 are ints, so the arithmetic is done using int math. Inconveniently, the value of that expression is (slightly) greater than Integer.MAX_VALUE so overflow occurs. Thus the negative value which gets assigned to millisInMonth. The fix is to force long math: long millisInMonth = (long)1000 * 60 * 60 * 24 * 30; This should probably go in some sort of Java-puzzle magazine article. :-) Jeff -Original Message- From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 1:09 AM To: Orion-Interest Subject: RE: Database schema type mappings Jeff, about the bug you mention... that sounds very strange to me and it sure should not have anything to do with byte size, I think. The value millisInMonth easily fits into a long... So if you have a long representing the current time milliseconds and subtract one month of milliseconds, yes, that should definately produce a time last month. I would like to know if I am wrong in this assumption or what the bug REALLY was about (?) R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: 1. marts 2001 02:38 To: Orion-Interest Subject: RE: Database schema type mappings You're thinking C++. In Java: A long is 8 bytes, always. An int is 4 bytes, always. The byte-orders are fixed independent of the hardware, too. Speaking of byte size, here's something I found amusing (and annoying): long millisInMonth = 1000 * 60 * 60 * 24 * 30; Date thirtyDaysAgo = new Date(); thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth); This actually produces a date in the FUTURE! It took me a while to hunt down this bug because it had really wierd effects on my application. Jeff -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 11:02 AM To: Orion-Interest Subject: RE: Database schema type mappings Randahl, We use the primitive long for all of our primary keys for a couple of reasons: * primary keys can't be null so there isn't a need for Long (or Integer) * long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which is currently not a problem but could be when Itanium platforms come out. int's depend on the CPU's native integer type which happens to be 32bits on ix86 architectures. Michael Third Chief Software Architect parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, February 28, 2001 10:02 AM To: Orion-Interest Subject: Database schema type mappings If you look at the database schema in "orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping between the primitive java type "int" and the corresponding database type "int": type-mapping type="int" name="int" /. In my EJBs my primary keys and other attributes are of type Integer. Since there is no mapping for class Integer one could think that Integers would be mapped to VARBINARY. Luckily my integers are mapped to the database type "int", but this makes me ask two questions: 1. Why is Integers automatically converted to int by Orion - and is this a standard EJB convention? 2. Would it be legal to have a primary key of the primitive type "int" instead of Integer? Yours Randahl
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
Re: Database schema type mappings
- Original Message - long millisInMonth = (long)1000 * 60 * 60 * 24 * 30; This should probably go in some sort of Java-puzzle magazine article. :-) I think this is a standard situation in Java and C. Most programmers would probably write it as long millisInMonth = 1000L * 60L * 60L * 24L * 30L; only casting "(long)1000..." is safe only as long as the remainder of the expression fits an int. Use non-captital "l" rather than "L" as in long millisInMonth = 1000 * 60 * 60 * 24l * 30; // right long millisInMonth = 1000 * 60 * 60 * 241 * 30; // wrong for Your Java puzzle. Depending on the font used it may be impossible to spot the error ;-))
RE: Database schema type mappings
Jeff wrote: This should probably go in some sort of Java-puzzle magazine article. :-) ROFL ! - I am glad you shared that top-secret-hard-to-find-under-cover-bug experience with us; I too might have used a lot of time finding out... in fact I think most developers would. Randahl -Original Message- From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 1:09 AM To: Orion-Interest Subject: RE: Database schema type mappings Jeff, about the bug you mention... that sounds very strange to me and it sure should not have anything to do with byte size, I think. The value millisInMonth easily fits into a long... So if you have a long representing the current time milliseconds and subtract one month of milliseconds, yes, that should definately produce a time last month. I would like to know if I am wrong in this assumption or what the bug REALLY was about (?) R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: 1. marts 2001 02:38 To: Orion-Interest Subject: RE: Database schema type mappings You're thinking C++. In Java: A long is 8 bytes, always. An int is 4 bytes, always. The byte-orders are fixed independent of the hardware, too. Speaking of byte size, here's something I found amusing (and annoying): long millisInMonth = 1000 * 60 * 60 * 24 * 30; Date thirtyDaysAgo = new Date(); thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth); This actually produces a date in the FUTURE! It took me a while to hunt down this bug because it had really wierd effects on my application. Jeff -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 11:02 AM To: Orion-Interest Subject: RE: Database schema type mappings Randahl, We use the primitive long for all of our primary keys for a couple of reasons: * primary keys can't be null so there isn't a need for Long (or Integer) * long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which is currently not a problem but could be when Itanium platforms come out. int's depend on the CPU's native integer type which happens to be 32bits on ix86 architectures. Michael Third Chief Software Architect parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, February 28, 2001 10:02 AM To: Orion-Interest Subject: Database schema type mappings If you look at the database schema in "orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping between the primitive java type "int" and the corresponding database type "int": type-mapping type="int" name="int" /. In my EJBs my primary keys and other attributes are of type Integer. Since there is no mapping for class Integer one could think that Integers would be mapped to VARBINARY. Luckily my integers are mapped to the database type "int", but this makes me ask two questions: 1. Why is Integers automatically converted to int by Orion - and is this a standard EJB convention? 2. Would it be legal to have a primary key of the primitive type "int" instead of Integer? Yours Randahl
RE: Database schema type mappings
I went digging through the EJB 1.1 specification, and it doesn't specifically say you can't use primitive types, but it does say they primary key class needs to be serializable. I have created a number of EJB's using the primitive long as the primary key and have had no problems using them. So I went back and looked at the deployment descriptor (it was originally generated by EJBMaker) and noticed that they prim-key-class was "java.lang.Long". All of the EJB class files are using the primitive type. It appears that at least Orion maps them intelligently(if not according to spec). On closer examination of the EJB 2.0 spec, I found these statements. * The primary key type must be a legal Value Type in RMI-IIOP. (this includes long) * The container must be able to manipulate the primary key type of an entity bean. * Primary key (must be a class or type?) that maps to a single field in the entity bean class. * The (create) method must declare the primary key class as the method argument. According to this statements, the primary key class and the primary key type don't necessarily have to be the same. Orion does allow the create method to accept the primary key type as opposed to the class, which isn't according to spec. Thanks, Michael PS - After my response on Java primitive data-types, I should probably keep my mouth shut for a while :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Thursday, March 01, 2001 6:12 AM 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
RE: Database schema type mappings
Correction: The last bullet should be: * The home interface must always include the findByPrimaryKey method, which is always a single-object finder. The method must declare the primary key class as the method argument. Michael -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 11:46 AM To: Orion-Interest Subject: RE: Database schema type mappings I went digging through the EJB 1.1 specification, and it doesn't specifically say you can't use primitive types, but it does say they primary key class needs to be serializable. I have created a number of EJB's using the primitive long as the primary key and have had no problems using them. So I went back and looked at the deployment descriptor (it was originally generated by EJBMaker) and noticed that they prim-key-class was "java.lang.Long". All of the EJB class files are using the primitive type. It appears that at least Orion maps them intelligently(if not according to spec). On closer examination of the EJB 2.0 spec, I found these statements. * The primary key type must be a legal Value Type in RMI-IIOP. (this includes long) * The container must be able to manipulate the primary key type of an entity bean. * Primary key (must be a class or type?) that maps to a single field in the entity bean class. * The (create) method must declare the primary key class as the method argument. According to this statements, the primary key class and the primary key type don't necessarily have to be the same. Orion does allow the create method to accept the primary key type as opposed to the class, which isn't according to spec. Thanks, Michael PS - After my response on Java primitive data-types, I should probably keep my mouth shut for a while :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Thursday, March 01, 2001 6:12 AM 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
Re: Database schema type mappings
Actually, a more proper way is to indicate to the compiler that you want long arithmetic by writing: long millisInMonth = 1000L * 60L * 60L * 24L * 30L Oh, and by the way, this is not really correct since you're assuming 30 days in a month. You should use the Calendar to figure out how many millis a given month actually has since this varies by month and year. - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, March 01, 2001 3:50 AM Subject: RE: Database schema type mappings Yes, it fits into a long, but by default constants like 1000 * 60 * 60 * 24 * 30 are ints, so the arithmetic is done using int math. Inconveniently, the value of that expression is (slightly) greater than Integer.MAX_VALUE so overflow occurs. Thus the negative value which gets assigned to millisInMonth. The fix is to force long math: long millisInMonth = (long)1000 * 60 * 60 * 24 * 30; This should probably go in some sort of Java-puzzle magazine article. :-) Jeff -Original Message- From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 1:09 AM To: Orion-Interest Subject: RE: Database schema type mappings Jeff, about the bug you mention... that sounds very strange to me and it sure should not have anything to do with byte size, I think. The value millisInMonth easily fits into a long... So if you have a long representing the current time milliseconds and subtract one month of milliseconds, yes, that should definately produce a time last month. I would like to know if I am wrong in this assumption or what the bug REALLY was about (?) R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: 1. marts 2001 02:38 To: Orion-Interest Subject: RE: Database schema type mappings You're thinking C++. In Java: A long is 8 bytes, always. An int is 4 bytes, always. The byte-orders are fixed independent of the hardware, too. Speaking of byte size, here's something I found amusing (and annoying): long millisInMonth = 1000 * 60 * 60 * 24 * 30; Date thirtyDaysAgo = new Date(); thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth); This actually produces a date in the FUTURE! It took me a while to hunt down this bug because it had really wierd effects on my application. Jeff -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 11:02 AM To: Orion-Interest Subject: RE: Database schema type mappings Randahl, We use the primitive long for all of our primary keys for a couple of reasons: * primary keys can't be null so there isn't a need for Long (or Integer) * long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which is currently not a problem but could be when Itanium platforms come out. int's depend on the CPU's native integer type which happens to be 32bits on ix86 architectures. Michael Third Chief Software Architect parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, February 28, 2001 10:02 AM To: Orion-Interest Subject: Database schema type mappings If you look at the database schema in "orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping between the primitive java type "int" and the corresponding database type "int": type-mapping type="int" name="int" /. In my EJBs my primary keys and other attributes are of type Integer. Since there is no mapping for class Integer one could think that Integers would be mapped to VARBINARY. Luckily my integers are mapped to the database type "int", but this makes me ask two questions: 1. Why is Integers automatically converted to int by Orion - and is this a standard EJB convention? 2. Would it be legal to have a primary key of the primitive type "int" instead of Integer? Yours Randahl
RE: Database schema type mappings
From: Chad Stansbury [mailto:[EMAIL PROTECTED]] Actually, a more proper way is to indicate to the compiler that you want long arithmetic by writing: long millisInMonth = 1000L * 60L * 60L * 24L * 30L I'm sure it all gets optimized out to the same thing in the end :-) But yes, you're right. I can imagine what engineers 10 years from now are going to be saying when they write Java code - damn thing only uses 32 bit math by default! How silly on our (32 * whatever) bit chips! :-) It certainly beats erratic machine-specific behavior though. Oh, and by the way, this is not really correct since you're assuming 30 days in a month. You should use the Calendar to figure out how many millis a given month actually has since this varies by month and year. The problem is not that particular. It's just a "what happened in the last 30 days" search bound. Jeff
RE: Database schema type mappings
Thanks for your input. An additional argument here might be that if you are not the only developer working on your EJB system, and if the system is to be maintained and expanded over time by many different software developers in a large organisation, it would probably be best to use only a single type of key for the same EJB (both in the bean class files and in the xml files) - and that would have to be the wrapper class, of course. - All these mails confirm that using different kinds of keys cause confusion, and I see no reason to confuse future developers of a system. But that is my personal view of course - and from the systems I have met so far in my career I sure know that not all developers think this way. Randahl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael A Third Sent: 1. marts 2001 17:46 To: Orion-Interest Subject: RE: Database schema type mappings I went digging through the EJB 1.1 specification, and it doesn't specifically say you can't use primitive types, but it does say they primary key class needs to be serializable. I have created a number of EJB's using the primitive long as the primary key and have had no problems using them. So I went back and looked at the deployment descriptor (it was originally generated by EJBMaker) and noticed that they prim-key-class was "java.lang.Long". All of the EJB class files are using the primitive type. It appears that at least Orion maps them intelligently(if not according to spec). On closer examination of the EJB 2.0 spec, I found these statements. * The primary key type must be a legal Value Type in RMI-IIOP. (this includes long) * The container must be able to manipulate the primary key type of an entity bean. * Primary key (must be a class or type?) that maps to a single field in the entity bean class. * The (create) method must declare the primary key class as the method argument. According to this statements, the primary key class and the primary key type don't necessarily have to be the same. Orion does allow the create method to accept the primary key type as opposed to the class, which isn't according to spec. Thanks, Michael PS - After my response on Java primitive data-types, I should probably keep my mouth shut for a while :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Thursday, March 01, 2001 6:12 AM 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
RE: Database schema type mappings
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
RE: Database schema type mappings
Randahl, We use the primitive long for all of our primary keys for a couple of reasons: * primary keys can't be null so there isn't a need for Long (or Integer) * long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which is currently not a problem but could be when Itanium platforms come out. int's depend on the CPU's native integer type which happens to be 32bits on ix86 architectures. Michael Third Chief Software Architect parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, February 28, 2001 10:02 AM To: Orion-Interest Subject: Database schema type mappings If you look at the database schema in "orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping between the primitive java type "int" and the corresponding database type "int": type-mapping type="int" name="int" /. In my EJBs my primary keys and other attributes are of type Integer. Since there is no mapping for class Integer one could think that Integers would be mapped to VARBINARY. Luckily my integers are mapped to the database type "int", but this makes me ask two questions: 1. Why is Integers automatically converted to int by Orion - and is this a standard EJB convention? 2. Would it be legal to have a primary key of the primitive type "int" instead of Integer? Yours Randahl
RE: Database schema type mappings
You're thinking C++. In Java: A long is 8 bytes, always. An int is 4 bytes, always. The byte-orders are fixed independent of the hardware, too. Speaking of byte size, here's something I found amusing (and annoying): long millisInMonth = 1000 * 60 * 60 * 24 * 30; Date thirtyDaysAgo = new Date(); thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth); This actually produces a date in the FUTURE! It took me a while to hunt down this bug because it had really wierd effects on my application. Jeff -Original Message- From: Michael A Third [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 11:02 AM To: Orion-Interest Subject: RE: Database schema type mappings Randahl, We use the primitive long for all of our primary keys for a couple of reasons: * primary keys can't be null so there isn't a need for Long (or Integer) * long's are always 4 bytes no matter what the CPU (32bit vs 64bit), which is currently not a problem but could be when Itanium platforms come out. int's depend on the CPU's native integer type which happens to be 32bits on ix86 architectures. Michael Third Chief Software Architect parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, February 28, 2001 10:02 AM To: Orion-Interest Subject: Database schema type mappings If you look at the database schema in "orion/config/database-schemas/hypersonic.xml" it looks as if it is mapping between the primitive java type "int" and the corresponding database type "int": type-mapping type="int" name="int" /. In my EJBs my primary keys and other attributes are of type Integer. Since there is no mapping for class Integer one could think that Integers would be mapped to VARBINARY. Luckily my integers are mapped to the database type "int", but this makes me ask two questions: 1. Why is Integers automatically converted to int by Orion - and is this a standard EJB convention? 2. Would it be legal to have a primary key of the primitive type "int" instead of Integer? Yours Randahl
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
