db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Commented: (DERBY-695) Re-enable the TINYINT datatype
Date Sat, 12 Nov 2005 02:33:30 GMT
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

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

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

Again, don't take this as an attack on TINYINT, I'm just trying to
ensure we see all the issues.


View raw message