Yes, that is what would happen if the SQL type code is the one for
TIMESTAMP. In that case we know when we read the item from the
resultset to use the get function that returns a java timestamp object
(sorry for being fuzzy here - I don't have the interface info
available). The problem is that when re read the resultset we don't
know what kind of object we are looking at because the database tells us
that the SQL type for that field is a code that is not listed in
java.sql.Types. Therefore we dare not try to interpret the data because
we do not know what it is.
My gut feeling is that Maury's idea of including DBMS-specific
renderer/editor classes in plugins could work. There is already an
interface that the DataType classes need to use (currently only used
internally in the core code, but what the heck). We'ld need to add a
way for the plug-in to register a class to associate it with a given SQL
type code, but that should be easy to do. Then it would be "just" a
matter of finding people willing to do the codeing and testing. :-)
Glenn
KosherJava wrote:
> In regard to the Timestamp, Wouldn't Timestamp.valueOf(String) work? When you display the timestamp, Java always uses the format of: yyyy-MM-dd hh:mm:ss.fffffffff and this is the format that valueOf expects. Since this is in the API documentation I would expect all drivers to adhere to it. The driver would then convert the Timestamp into the format expected by the DB. At least this is the way DB2 works. (natively it does not use the yyyy-MM-dd hh:mm:ss.fffffffff format, but the Timestamp generated by valueOf() converts it to the properly formatted Timestap.
>
> -----Original Message-----
>
> 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...
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squirrel-sql-develop@...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
>
>
|