Hi Jörg,
yes, that's true.. however the last driver version (10g) seems to have solved a couple of problems with BLOBs..Particularly the Oracle JDBC drivers used to give a lot of problems when trying to use 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.
The JDBC interface is probably a bit clumsy... the setTimestamp seems the only way to set both Date and Time in the same field.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.
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Fabio Insaccanebbia
INSAC.COM
e-mail: [EMAIL PROTECTED] - URL: http://www.insac.com <http://www.insac.com/>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
