Be or not to be: Versionmare on MySQL?

What the fuck! Im sorry but this gettin one big hole, i hope…

If you have currently MySQL as Database running and the driver version 5.0.x on start, i expect you getting some errors when you using BinaryObjects for exchange between different layers. When you using this driver-version 3, you should getting errors if you run a statement like this:

PreparedStatement ps = this.connection.
prepareStatement("UPDATE EXPLORER SET DATA = ? WHERE ID = ?");
ps.setBinaryStream(1, is);
ps.setBinaryStream(1, is, file.length);

Because, when using this version of the connector some  methods not being implemented yet. The exception that leads you to more suicde-cogitations is:

SCHWERWIEGEND: Servlet.service() for servlet Webdav threw exception
java.lang.AbstractMethodError: com.mysql.jdbc.Server
PreparedStatement.setBinaryStream(ILjava/io/InputStream;)V
at de.krypthonas.webdav.service.ResourceServiceImpl$$M$495371fc
.streamIn(ResourceServiceImpl.java:429)

Abstract hmm? Okay, cool. Because during the development of version 3 of the connector for java/mysql some developer thoughts: hey its pretty cool for leading some methods abstract (or not being right implemented). So programmers have on all cases more fun looking for the error. Its like easter!!! Sorry for my cynicism today.

Right there. If we update current version of the connector to 5.1.7, we can now done this job. I dont know at all, why blobs are such problems for database-vendors to implement. Of course, there are many problems and situations being solved very well, but hey? Java is a little bit older a think.

So, where was I? Oh yes. After updating the version you have the JDBC Version 4, so thos methods are very well implemented and you can use this. But there is another fallback, i have to say:

Until now, when you wanted a auto_inc key from the database, you´ve defined a flag-like parameter at statement-creation time:

Statement stmt = this.connection.createStatement(
Statement.CLOSE_ALL_RESULTS,
Statement.RETURN_GENERATED_KEYS);

...

stmt.executeQuery(sqlQuery);
ResultSet generatedKeys = stmt.getGeneratedKeys();

But now, you running into the next black hole.  Your productivity will be punished with exception below:

java.sql.SQLException: !Statement.GeneratedKeysNotRequested!
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926)
at com.mysql.jdbc.StatementImpl.getGeneratedKeys(StatementImpl.java:1814)

What can we do now? We moving our code liable for auto_inc into the executeQuery method as parameters:

stmt.execute(sqlQuery, Statement.RETURN_GENERATED_KEYS);
ResultSet generatedKeys = stmt.getGeneratedKeys();

October 25, 2008 | Filed Under MySQL, Java

 

Comments

One Response to “Be or not to be: Versionmare on MySQL?”

  1. JIRA: Operations on December 5th, 2008 10:17 pm

    [OPS-29] Upgrade to MySQL JDBC driver version 5.1.7…

    This upgrade is on hold. Email from Chris on December 2:

    I’m running into an error with the new JDBC 5.1.7 driver. When I save a job from the search results page, the server spews an error like this:

    !Statement.GeneratedKeysNotRequested! (and …

Leave a Reply




Security Code: