db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-695) Re-enable the TINYINT datatype
Date Sat, 12 Nov 2005 12:49:53 GMT


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

Mime
View raw message