Maury,
Thanks for looking them up...
Maury Hammel wrote:
> Glenn:
>
>> Well, that depends....
>> The data type in the DBMS gets mapped to a SQL type code somewhere
>> (either in the DBMS or in the Java driver - I don't know). There is a
>> list of standard "known" codes in java.sql.Types.java, but every DBMS
>> I've seen so far implements lots of other data types that do not map
>> to codes in that file. The only codes that we can reliably build
>> editors for are those in the Types.java file (since different DBMSs
>> might use the same non-standard code for different purposes).
>> Therefore, to know if we will be able to create an editor for the
>> NUMBER type, we will need to know the SQL code used by Oracle for that
>> type. This can be found in the COLUMNS tab field named "DATA_TYPE".
>> If you let me know what that number is, I can tell you if it is
>> possible to make an editor for it, but we still won't know whether
>> we'll get around to it or not.
>
>
> Ah, okay. I did a quick check of some databases and got the types that
> don't appear to be editable:
>
> TYPE_NAME value DATA_TYPE value java.sql.Types.?
> --------------- --------------- -------------------------
> NUMBER 3 java.sql.Types.DECIMAL
> DATE 93 java.sql.Types.TIMESTAMP
> TIMESTAMP 1111 java.sql.Types.OTHER
> BLOB 1111 java.sql.Types.OTHER
> CLOB 1111 java.sql.Types.OTHER
>
> Ugh, I don't like the look of the TIMESTAMP, BLOB and CLOB values. Can
> you not base the decision about editing on the "TYPE_NAME" column? Or
> will there be the API to allow a database-specific plug-in to handle the
> 'OTHER's?
I don't like their looks either :-).
The problem is how to handle things that do not have a "standard" type
associated with them. What java object are they transformed into
internally? What rules do we allow/disallow on editing of the string
representation of that type?
The 3 OTHERs listed here are prime examples of the problems. Each DBMS
seems to have its own representation of TIMESTAMP, and there is no
guarantee that they would look or work the same from one DBMS to
another. Does your DMBS include milliseconds? Yes? Well too bad - we
couldn't include those because someone else's DBMS does not allow them.
Your DBMS wants TIMESTAMPs as "hh:mm:ss"? Well your neighbor's stores
them in "seconds since beginning of the epoch". You get the idea.
BLOBs and CLOBs are even worse. You may have noticed in java.sql.Types
that BLOB and CLOB have special codes of their own (2004 & 2005
respectivly). These have special meaning since they are handled by Blob
and Clob objects within Java. When you get the data from the resultset,
you read it into a Blob/Clob object which does _not_ include the actual
data. That column data is read from the DB by making a call on the
Blob/Clob object. Since Oracle maps type-name "BLOB" to
java.sql.Type.OTHER, it would not use that 2-stage mechanism, and thus
would not operate as a "BLOB" should, even though it has that name.
(Actually, this surprises the heck out of me since I had the impression
from some info from Colin that Oracle had real BLOB/CLOB types, not
something fudged. By the way, every DBMS I've been able to get running
on my machine uses some funky non-standard BLOB/CLOB mechanism while
calling the types "BLOB" and "CLOB". Postgess actually stores them as
LONGVARBINARY objects!)
So you see my problem is how to handle things consistantly from DBMS to
DBMS when the DMBS manufacturers haven't agreed on how to handle things
consistantly. I really think that relying on the name would get us in
trouble (witness the "BLOB/CLOB" case). I haven't thought about the
DBMS-specific plug-in approach, but that might work. Any other good ideas?
Glenn
>
>
> Maury...
|