Re: [jira] Commented: (DERBY-695) Re-enable the TINYINT datatype

[Lance J. Andersen]

Daniel John Debrunner wrote: Rick Hillegas wrote: I logged this enhancment request because it seemed that re-enabling TINYINT would be low hanging fruit. I believe how hard or easy an item is has no relevance to if it should be included in Derby. The criteria should be, is it good for Derby given Derby's charter. Furthermore, to me TINYINT should be a signed integer just like its bigger sisters SMALLINT, INTEGER, and LONG. It makes sense to me that the premier Java database should have datatypes which correspond as exactly as possible with the Java datatypes. This would be the most natural fit for persisting the data from Java applications, whether flattened by hand or by off-the-shelf O-R mapping technologies. OK, I was misled by the comment in DERBY-695 that TINYINT was a good thing because other databases supported it. If that's not the driving factor, then it's different proposal. Currently, we are missing two of these Java datatypes: boolean (java.sql.BOOLEAN) and byte (java.sql.TINYINT). Exposing a signed TINYINT does not violate any standard we care about: ANSI is silent on the matter, and JDBC is compatible with this interpretation. A signed TINYINT would be an easy, natural, and useful addition for the Java applications which are our bread-and-butter customers. How much demand for this type, as you've described is there? Are many Java applications using byte for fields? My guess would have been that any requests for TINYINT would have been due to existing database applications. Well, certainly MySQL added long after Sybase, so i am sure there are some apps using it.  One potential issue is that we are creating a non-standard datatype that is in conflict with the existing type of the same name by SQL Server and Sybase. Will this cause more problems for users of Derby as they try to migrate off those databases? Of course in some ways it's not much better if we go 0-255, as then it's in conflict with MySQL. Though I would be interested to know if the new strict flag in MySQL has any effect on TINYINT. There are range issues across many databases with datatypes.  Again, you have to know the range of the datatype on the backend to make sure it works for you. So, does adding this datatype solve more problems than it creates? How does it compare to having the JDBC drivers map JDBC type TINYINT to SQL Type SMALLINT? So map it to an existing datatype then such as SMALLINT, just allow for the DDL to be processed when defined as a TINYINT. Again, don't take this as an attack on TINYINT, I'm just trying to ensure we see all the issues. Understand, but i am not sure what else can be said about this datatype. So how do we close on this issue as we seem to be not moving forward? Dan.