db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabio Insaccanebbia <finsaccaneb...@gmail.com>
Subject Re: AW: BLOB and CLOB Torque datatypes
Date Mon, 09 May 2005 16:40:47 GMT
Hi Jörg,

>Particularly the Oracle JDBC drivers used to give a lot of problems when trying to use
BLOBs.
>
yes, that's true.. however the last driver version (10g) seems to have 
solved a couple of problems with BLOBs..
The choice of "avoiding" BLOBS in an application is probably a good one: 
Torque, on the other side, should try
to "solve" or "reduce" the problems with BLOB using so that the 
application developers can choose to use BLOBs
without too many issues.

>With regard to mapping, there is another problem with date, datetime and
>timestamp, particularly with newer versions of MySQL which have a very
>peculiar handling of these types. Even though there is no DATETIME data type
>in the JDBC interface we may have to provide the possibility to define such
>in the schema.xml file, since some DBMS use it and clearly distinguish
>between timestamp, date, and datetime.
>
The JDBC interface is probably a bit clumsy... the setTimestamp seems 
the only way to set both Date and Time in the same field.
I'm afraid that some driver creators decided to "overcome" this JDBC 
limit by ignoring the setDate specified behaviour.

I agree with the DATETIME proposal: this could give us the flexibility 
to work around driver's strange behaviours.

Regards,
Fabio

Jörg Friedrich wrote:

>Hi Thomas,
>
>BLOBs/CLOBs are a difficult issue. In the Track+ application we have gotten
>around the problems with BLOBS by not using them. Particularly the Oracle
>JDBC drivers used to give a lot of problems when trying to use BLOBs.
>
>Please allow me to point out some issues in this context: we have used
>VARCHAR for our description fields. The maximum size of VARCHAR depends on
>the DBMS used. For example, in MySQL a VARCHAR may be up to 255 characters
>long, in Oracle 4000 and in Interbase/Firebird 32000, to name just a few. So
>how do you define your database scheme such that it works on all supported
>database systems? Actually you really can't and you have to patch your
>output. Using BLOBs instead may not always work since BLOBs behave
>differently on some database systems when trying to include them in the
>where or sort clause of select statements. So BLOBs and CLOBs are nice, but
>from what I have seen they are the least portable datatype in the DBMS
>world.
>
>How could you get around this? I think the only way is to be able to define
>user data types and let the user do the mapping. For example, I could define
>a type <Description> and map it to TEXT in MySQL, VARCHAR2(4000) in Oracle,
>and VARCHAR(32000) for Firebird. The definition could be part of the
>schema.xml file, which would then have to include mapping information
>(beyond the default mapping which can work as is) for the database systems
>you care about in your project.
>
>With regard to mapping, there is another problem with date, datetime and
>timestamp, particularly with newer versions of MySQL which have a very
>peculiar handling of these types. Even though there is no DATETIME data type
>in the JDBC interface we may have to provide the possibility to define such
>in the schema.xml file, since some DBMS use it and clearly distinguish
>between timestamp, date, and datetime.
>
>Regards,
>
>Joerg
>
> 
>
>-----Ursprüngliche Nachricht-----
>Von: Thomas Fischer [mailto:tfischer@apache.org] 
>Gesendet: Sonntag, 8. Mai 2005 21:47
>An: torque-dev@db.apache.org
>Betreff: BLOB and CLOB Torque datatypes
>
>
>Hi,
>
>I am pondering about which datatypes should be mapped to the Torque BLOB 
>and CLOB types, and which should not. Background is that "real" Blob and 
>CLOB data types are handled differently by the jdbc drivers than other 
>types, in the sense that for a CLOB or BLOB column, one does not get the 
>value directly, but a stream from which one can read (or into which one 
>can write). So, in a sense, for "normal" datatypes, you get the 
>value directly, for BLOB/CLOB, you get a reference. Torque hides this 
>different behaviour from the user.
>
>So I would suggest that we define a minimum length for which we assume 
>that a column is a "large object". For the columns that I have in mind to 
>change (Postgresql BYTEA-> Blob, HSQLDB LONGVARBINARY -> BLOB, HSQLDB 
>LONGVARCHAR -> CLOB) these objects can be up to 2^32 bytes/characters 
>long. But if a data type in a database meets this length criterium, we do 
>not care whether it can be accessed in a blob-scpecific way or not, we 
>just map the BLOB/CLOB Torque types to these values.
>
>Any comments, objections etc ?
>
>          Thomas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
>For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
>For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
>  
>


-- 

Fabio Insaccanebbia 

INSAC.COM

e-mail: finsaccanebbia@insac.com - URL: http://www.insac.com 
<http://www.insac.com/>

 


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message