2013/2/15 digulla <[email protected]>: > On Friday, February 15, 2013 1:25:07 PM UTC+1, Lukas Eder wrote: > >> 2. Maintain your own JDBC implementation (infrequent changes that are >> easy to maintain) > > > How do I write a unit test that tests a piece of code with Java 5, 6 and 7?
jOOQ doesn't officially support Java 5 ;-) Also, jOOQ doesn't call JDBC methods from Java 7. To stay compliant with JDBC 4.1, jOOQ offers org.jooq.tools.jdbc.JDBC41Connection and similar methods, providing method stubs for the added methods in JDBC 4.1 So when using jOOQ, you only have to "support" JDBC 4.0 > Each of these versions uses a different, incompatible JDBC API and I'm > pretty sure that Java 8 will include JDBC 4.2. Yes, but with Java 8, extension methods are in place. Check out Statement: http://hg.openjdk.java.net/lambda/lambda/jdk/file/ee1fce80ec31/src/share/classes/java/sql/Statement.java It contains: 1091 default long getLargeUpdateCount() throws SQLException { 1092 throw new UnsupportedOperationException("getLargeUpdateCount not implemented"); 1093 } Beautiful, eh? :-) > I feel that you simply say "JDBC mock is much easier" because you never > actually tried to build one. I wrote 3 JDBC drivers, [...] jOOQ has a couple of JDBC implementations. That's not the same as implementing a driver, of course. > I wrote patches to > MockRunner and I wrote unit tests using MockRunner. The JDBC API, frankly, > sucks. From all the Java APIs, it's the most complex by far, it's the most > brittle and the one where they broke every rule regarding API evolution. It sucks, yes. But it's a well-defined API, unlike jOOQ's internals. > JDBC is so complicated that it took Oracle more than 10 years to build a > driver which doesn't have many major bugs like leaking Cursors when using > BLOBs. I doubt that this is because of JDBC. BLOBs are a nasty thing in a database that doesn't support VARCHAR2(N) with N > 4000... > Just look at org.jooq.impl.FieldTypeHelper.getFromResultSet(ExecuteContext, > Class<? extends T>, int) to get an idea how much of the ResultSet API I'd > have to replicate. Here's another suggestion: Since I... - really don't want to give any guarantee about jOOQ's internals to you - understand your use-case - want to add value for the community I could implement MockConnection, MockStatement, etc. There could be something like a MockDataProvider: interface MockDataProvider { // Callback for org.jooq.Query queries int execute(String sql, Object[] bindValues); // Callback for org.jooq.ResultQuery queries // The actual signature may vary, in order to // be able to implement ResultSetMetaData Object[][] fetch(String sql, Object[] bindValues); } You as a user would only have to implement this MockDataProvider and pass it to the jOOQ Factory like this: new Factory(new MockConnection(new MyMockDataProvider()), dialect); What about this approach? I'd be willing to maintain and integration test such an API - without competing with DBUnit and other tools, of course. > And even when I could mock Cursor.fetch(), ResultImpl is package private so > I'd have to cut&paste these 1931 lines to implement Result unless putting my > code into org.jooq.impl which I don't like. Well, jOOQ would hardly evolve if I didn't keep the impl parts package private. Every release would be a major release, then... -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
