Ok, the code is committed (I did put a comment in Jira too).
I tested everything with mssql, and it is ok, and I confirm that it can not use
getBlob.
Other tests should now be done, and I would fill in the following table, taking out
the "?"s:
DB Product | useBlob works | we will use | tested by |
------------+-----------------+---------------+-------------+
mssql | false | useBytes | Vincenzo |
oracle | true? | useBlob | |
mysql | true? | useBytes? | |
postgresql | | useBytes? | |
sapdb | | useBytes? | |
hypersonic | | useBytes? | |
db2 | true? | useBlob? | |
ingres | | useBytes? | |
------------+-----------------+---------------+-------------+
My suggestion (and I followed this line setting SqlResources and the defaults in the
code) is to keep things working as before (getBytes) and switch to getBlob only if
really needed (or useful for some reason). The SqlResources I just committed to cvs is
as in the "we will use" column above. This should make everything compatible with the
current james sites around.
A snippet of the SqlResource.xml committed follows:
*****************************************************
<!--
With the following section it is possible to associate several name/value pairs
of options to a database product, identified by the "db" XML attribute name.
An element without a "db" attribute, if used for an option name, will become a
default value for such option.
Each option may have a "default default", i.e. a default that applies if no
element with an empty
"db" attribute (default element) exists as said above;
such default default must be documented for such option below.
The order of the XML elements is meaningless.
Here only "getBody" and "getAttributes" option names are set, but others could be
used in the future.
Option names:
"getBody" - a string (case insensitive) telling which JDBC ResultSet method
will be used to
get the message body field for a database product.
The default default value is "useBytes"..
Values (case insensitive):
"useBytes" - use getBytes(int).
"useBlob" - use getBlob(int).
"getAttributes" - a string (case insensitive) telling which JDBC ResultSet
method will be used to
get the message attributes field for a database product.
The default default value is "useBytes"..
Values (case insensitive):
"useBytes" - use getBytes(int).
"useBlob" - use getBlob(int).
-->
<dbOptions>
<dbOption name="getBody" value="useBytes"/>
<dbOption name="getAttributes" value="useBytes"/>
<dbOption db="mssql" name="getBody" value="useBytes"/>
<dbOption db="mssql" name="getAttributes" value="useBytes"/>
<dbOption db="oracle" name="getBody" value="useBlob"/>
<dbOption db="oracle" name="getAttributes" value="useBlob"/>
<dbOption db="mysql" name="getBody" value="useBytes"/>
<dbOption db="mysql" name="getAttributes" value="useBytes"/>
<dbOption db="postgresql" name="getBody" value="useBytes"/>
<dbOption db="postgresql" name="getAttributes" value="useBytes"/>
<dbOption db="sapdb" name="getBody" value="useBytes"/>
<dbOption db="sapdb" name="getAttributes" value="useBytes"/>
<dbOption db="hypersonic" name="getBody" value="useBytes"/>
<dbOption db="hypersonic" name="getAttributes" value="useBytes"/>
<dbOption db="db2" name="getBody" value="useBlob"/>
<dbOption db="db2" name="getAttributes" value="useBlob"/>
<dbOption db="ingres" name="getBody" value="useBytes"/>
<dbOption db="ingres" name="getAttributes" value="useBytes"/>
</dbOptions>
*************************************************
I added also the ingres support from Jason Tepoorten, adapted to 2.2.0x message
attributes, but couldn't test this part.
Vincenzo
> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: marted� 18 maggio 2004 20.56
> To: James Developers List
> Cc: Arjan Veenstra; Russ Ochsner; Jason Tepoorten
> Subject: RE: Reopened Jira JAMES-247
>
>
> Steve and Vincenzo:
>
> For the moment, we're planning to keep the current code as close to what it
> is as possible, but Vincenzo is modifying the XML so that it tell us to
> treat the column as bytes, blob or input stream. Down the road, we may have
> use of that flexibility. It would be nice to stream the data, for example,
> directly where the JDBC driver isn't broken. But for now, I think we're
> looking at trying the general XML, but only the two code paths (the "old"
> bytes code and the "new" blob code).
>
> This means we will revisit the PostgreSQL issues raised by Arjan and Russ,
> and try to add the additional configuration elements from Jason Tepoorten.
> I want to make sure that everyone has a heads up so that we can test the
> JDBC support on all of these drivers as soon as Vincenzo commits a change.
> I can put to a test build, not yet an RC until we've been able to validate.
> Can everyone try to make time to help test, please?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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]
