RE: [ojb-users] bindSelect() Error in setObject() call...

[Corey K. <Co...@kl...>]

Ok, I've done a some more digging, and it looks like I'm going to need to do
some work. I receive a "Driver not capable" error for any setXXX() parameter
binding call. This means, I will need to plug in a StatementsForClass that
uses custom PreparedStatement implementation which handles the object
binding and finally passes the query to a vanilla statement to execute the
resultant SQL. 

There are many ways to go about this, but I think it makes sense to add a
getStatementsForClassInstance() method to the Platform interface. Then,
instead of:

        ... 
        StatementsForClass sfc = (StatementsForClass)
statementTable.get(cds);
        if (sfc == null)
        {
            sfc = new StatementsForClass(cds, broker);
            statementTable.put(cds, sfc);
        }
        return sfc;
        ...

do this:

        ...
        StatementsForClass sfc = (StatementsForClass)
statementTable.get(cds);
        if (sfc == null)
        {
            sfc = pf.getStatementsForClass(cds, broker);
            statementTable.put(cds, sfc);
        }
        return sfc;
        ...

Then, an ojb.broker.jdbc.PreparedStatementImpl would need to be implemented.
This would give full on flexibility for brain-dead ODBC and/or JDBC
implementations such as my own. Does that sound like a reasonable approach?

Corey

Yes this is clearly a driver related issue.
Parameter binding is a common place for problems with all kind of drivers.
in the method ojb.broker.accesslayer.StatementManager.bindUpdate(...)
we solved this by delegating the binding to a Driver specific
Platform. The exact behaviour is thus delegated to a Driver specific class.

For ojb.broker.accesslayer.StatementManager.bindSelect(...), that causes
the problem in your case, this is not yet implemented, but could be
refactored quite easily.

But: I don't have access to your Jdbc driver. SO try to fix this bug on
your own, send in the patch, an we will refactor the Platform interface
to work for bindSelect(...) too.

 > Corey
 >
 > -----Original Message-----
 > From: Corey Klaasmeyer [mailto:Co...@kl...]
 > Sent: Wednesday, April 17, 2002 8:51 AM
 > To: 'Obj...@li...'
 > Subject: [ojb-users] Modifications to Work Around Lame ODBC Drivers...
 >
 >
 > Since I am working with a legacy ODBC driver from Simba, I have had 
to work
 > around exceptions which propogate up from that level. It would be 
great if I
 > could get some feedback on the implications of these changes -- all in
 > accesslayer.
 >
 > 1.) In ConnectionFactoryDefaultImpl, I commented out
 > conn.setAutoCommit(!broker.isInTransaction()).
 >


That's OK. In fact this been moved to the
PlatFormDefaultImpl.initializeJdbcConnection(...) method to allow
different behaviour for certain Platforms.
It's already in CVS !


 > I'm assuming autocommit can remain in its default state of true if
 > transactions are not being used.
 >


ACK


 > 2.) In StatementsForClass I commented out
 > result.setEscapeProcessing(ESCAPEPROCESSING);
 >



With my latest changes it is also possible to set the ESCAPEPROCESSING
   value at runtime from a PlatformImpl. Thus it won't be necessary to
comment out anything....


We just need a PlatformSimbaImpl doing all the special Simba things...

cu,

Thomas


 > It doesn't look like this should have any effect. This is the javadoc for
 > setEscapeProcessing():
 > Sets escape processing on or off. If escape scanning is on (the default),
 > the driver will do escape substitution before sending the SQL 
statement to
 > the database. Note: Since prepared statements have usually been 
parsed prior
 > to making this call, disabling escape processing for PreparedStatements
 > objects will have no effect.
 >
 > Finally, these are obviously not general solutions. I think you will 
need to
 > catch exceptions and react in some rational way. This may be a better 
mail
 > for the developers list...
 >
 > With these changes, OJB is now reading some simple records from our
 > lumbering accounting system.
 >
 > Corey
 >
 >
 >
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 >
 >
 >




_______________________________________________
Objectbridge-users mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-users