Hello,
>> So when using jOOQ, you only have to "support" JDBC 4.0
>
> This code would only compile with Java 6. Java 5 would complain about
> methods with @Override that don't exist in the interface and Java 7 would
> complain about unimplemented methods.
>
> I'm not sure what happens when you try to run this on Java 7. Do you get a
> MethodNotImplementedException at runtime?
It works perfectly. As I said, Java 5 is not supported by jOOQ, so the
@Override annotations aren't a problem. I don't see where Java 7
should cause problems, when my Connection implementations extend
JDBC41Connection.
Another option is to use proxies to implement JDBC interfaces. Then
you'll never run into problems and you can be compatible with Java 1.3
(whatever the JDBC version was back then)
> I could live with the Object[][] solution as well but it will make tests
> more brittle/less readable. If you use record types, you get all the
> advantages of the existing API (type safety, compile errors when the DB
> schema changes, ...) And you can use test data factories to quickly many
> records. We could even wire them correctly to the factory by using the
> newRecord() method of the returned test factor.
Yes, I've come to that conclusion, too. Assuming that we're talking
about the same: I'll probably introduce methods to the Factory that
allow for creating Tables with Fields, and then newRecord() can be
used to create records from such tables, and then newResult() should
be introduced to combine the whole thing.
Probably, MockDataProvider would have to look more like this:
------------------------------------------------------------
public interface MockDataProvider {
MockResult[] execute(String sql, Object[] bindings);
}
------------------------------------------------------------
... where MockResult holds some meta data. Still, this doesn't
correctly model batch statements
> I think queries are most important. But UPDATE/INSERT should be simple to
> add. I'm just not sure what the method names would be.
It should all be contained in a single method, as there is no real
restriction to whether DML methods can generate results. Take the
Postgres INSERT .. RETURNING statement. JDBC takes these facts into
account, even if the API is awkward.
> An additional feature would be throwsException(SQLException) to support
> testing error handling.
Good idea. So obviously, MockDataProvider.execute() should have a
throws SQLException clause
>> I could implement MockConnection, MockStatement, etc.
>
> Okay, have fun :-)
I'll send you a bill! ;-)
>> > 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...
>
> I don't doubt that. But I'm also 95% sure that doing what I want is much
> less effort by hiding it inside of jOOQ than by mocking JDBC. I don't know
> all the details how to do it and what the best solution would be and what
> parts of the API you can change, etc. But I'm sure this would be a great
> feature that will make testing DB related code more simple, more stable and
> much cheater to maintain than any other, existing approach.
And I'm very sure that you underestimate the complexity of patching
jOOQ. jOOQ also supports:
- fetchMany(), i.e. fetching several result sets
- fetchLazy(), i.e. fetching records one-by-one
- keepStatement(), i.e. sharing PreparedStatements among executions
- batch processing,
- fetchUpdatable(), i.e. fetching with ResultSet.CONCUR_UPDATABLE.
This is not yet implemented in jOOQ, though.
- etc.
So in the end, I'm not sure if it's really simpler to mock / patch
jOOQ rather than implementing those parts of JDBC that are used by
jOOQ. Given that jOOQ itself could use those MockConnection objects
itself for various unit / integration tests, I think we'll get much
more traction out of that approach, rather than doing something that
solves your immediate problems (which do not yet include
fetchMany/fetchLazy, batch/DML/etc.).
Cheers
Lukas
--
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.
