[Opensource] mysql "text" type handled with prepared statement

[Michael Rimov]

At 06:25 PM 12/3/2002 -0800, you wrote:
>hi,
>
>for mysql, all our long text fields in DBObject were defined as type 
>"longvarchar", and our JDBC setup employs the following type mapping
>
><type-mapping>
>         <java-type>LONGVARCHAR</java-type>
>         <expresso-type>text</expresso-type>
>         <db-type>text</db-type>
></type-mapping>
>
>expresso 5 (latest; haven't checked 5.0.x) has introduced handling for 
>prepared statements, and seems to require handling of both the text and 
>longvarchar types with prepared statements, in particular with the 
>following code in JDBCExecutor (line 484)
>
>                                 if (lobUpdates != null) {
>                                         java.sql.PreparedStatement 
> prepStatement = myConnection.createPreparedStatement(theSqlString);
>
>
>what is the best way around this?  we sacrifice efficiency with prepared 
>statements, according to our previous concensus on this list.

Hi Larry,

Yes, efficiency is going down some on using the Prepared statements.

HOWEVER, I have a batch of databases that map the arbitrary length text 
types to CLOBs.... and CLOBs must be updated via a prepared 
statement.  Which is why you see the if (lobUpdates != null)... I don't use 
prepared statements unless I have to.

[IIRC, I had this issues with Postgres 7.2, Firebird 1 and SapDB 7.3]

I suppose you can start adding database configuration values for which 
databases need which datatypes for Prepared statements.  But that never 
seemed like a particularly fun solution.

That's why you saw the prepared statements show up.  Now on the flip side, 
you can gain about 30% improvement under batch adds/updates because of the 
use of preparedStatements.

Hope this helps,

                                                         -Mike