Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
From: =?iso-8859-1?Q?J=F6rg_Friedrich?= <friedj@users.sourceforge.net>
To: "'Apache Torque Developers List'" <torque-dev@db.apache.org>
Subject: AW: BLOB and CLOB Torque datatypes
Date: Mon, 9 May 2005 17:37:54 +0200
Message-ID: <003a01c554ad$112db250$68266c86@fhtesslingen.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <20050508122835.T95388@minotaur.apache.org>

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

=20

-----Urspr=FCngliche Nachricht-----
Von: Thomas Fischer [mailto:tfischer@apache.org]=20
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=20
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=20
can write). So, in a sense, for "normal" datatypes, you get the=20
value directly, for BLOB/CLOB, you get a reference. Torque hides this=20
different behaviour from the user.

So I would suggest that we define a minimum length for which we assume=20
that a column is a "large object". For the columns that I have in mind =
to=20
change (Postgresql BYTEA-> Blob, HSQLDB LONGVARBINARY -> BLOB, HSQLDB=20
LONGVARCHAR -> CLOB) these objects can be up to 2^32 bytes/characters=20
long. But if a data type in a database meets this length criterium, we =
do=20
not care whether it can be accessed in a blob-scpecific way or not, we=20
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