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] Created: (DERBY-695) Re-enable the TINYINT datatype
Date Wed, 09 Nov 2005 23:03:47 GMT


David W. Van Couvering wrote:

> One could argue that adding TINYINT support makes it harder to migrate 
> applications from Derby *to* Oracle and DB2.  But it seems to me this 
> is easily mitigated by clearly documenting that this type is not 
> supported by databases X,Y,Z and thus should be avoided if your plan 
> is to migrate to that database in the future.

You could argue that but...

The concern IMHO is migrating  apps to Derby not away from Derby.  We 
need to make it easier for people to adopt.  You could always add a 
level of verbosity via a flag which generates warnings when 
non-compliant syntax is used in addition to adding a means to flag SQL 
compliance  to the docs for various syntax and datatypes.  SQL Anywhere 
does a pretty good job of that.  Oracle I believe has a chart in their 
docs which compares their datatypes and SQL standard datatypes along 
with a guide as to what they should map to

I would rather document SQL compliance (for more than just datatypes) 
than not support the datatype.


Besides the more vendors that support it, the sooner will be considered 
for adoption by the standards committee

>
> David
>
> Lance J. Andersen wrote:
>
>> I am for adding this datatype back.  While it may not be part of the 
>> SQL Standard, it is a common datatype supported by multiple vendors.  
>> Having this datatype supported helps with the migration of 
>> applications and at the end of the day making it easier for 
>> applications to migrate is more important than basing a decision 
>> soley on whether the datatype is supported by the SQL standards.
>>
>> +1 (unofficial vote) for this addition
>>
>> Rick Hillegas (JIRA) wrote:
>>
>>> Re-enable the TINYINT datatype
>>> ------------------------------
>>>
>>>         Key: DERBY-695
>>>         URL: http://issues.apache.org/jira/browse/DERBY-695
>>>     Project: Derby
>>>        Type: New Feature
>>>    Reporter: Rick Hillegas
>>>
>>>
>>> I would like to collect here the arguments for and against 
>>> re-enabling the TINYINT datatype. Once this discussion calms down, 
>>> we can schedule a vote on the issue.
>>>
>>> Background: Cloudscape used to support the TINYINT datatype, which 
>>> was an 8 bit int. This datatype was hidden from customers as part of 
>>> an effort to remove all datatypes not supported by DB2. Re-enabling 
>>> the datatype would not require a lot of effort. Some arguments for 
>>> and against re-enabling this datatype can be found on the November 
>>> 2005 email thread titled "New features for next release .... (Was: 
>>> Grant and Revoke ... DERBY-464...)".
>>>
>>> Here are the arguments in favor so far:
>>>
>>> + This datatype is defined by one of our key standards, JDBC. It is 
>>> in JDBC 2, 3, and 4, all of the JDBC revs supported by Derby 10.2.
>>> + This datatype is supported by some important databases, including 
>>> MySQL, Microsoft SQL Server, and Sybase.
>>>
>>> Here are the arguments against so far:
>>>
>>> - This datatype is not defined by our other key standard, ANSI SQL. 
>>> Here our two main standards diverge.
>>> - This datatype is not supported by some important databases, 
>>> including Oracle, DB2, and (some) Informix databases.
>>>
>>> Against this proposal, it was also argued that there was some sort 
>>> of friction with ODBC. I do not understand this argument: 
>>> SQL_TINYINT is an ODBC datatype. See 
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsql_data_types.asp.

>>>
>>>
>>> A friction with .NET was also suggested but I don't understand this 
>>> either. "byte" and "Sbyte" are the .NET 8-bit integer types. See 
>>> http://www.codersource.net/csharp_tutorial_data_types.html.
>>>
>>> A friction with Perl was also suggested but I don't understand this 
>>> either.
>>>
>>>
>>>
>>>  
>>>

Mime
View raw message