org.jooq.tools.jdbc

Interface MockDataProvider

All Known Implementing Classes:

MockFileDatabase

public interface MockDataProvider

A data provider for mock query executions.

Supply this data provider to your MockConnection in order to globally provide data for SQL statements.

See execute(MockExecuteContext) for details.

Author:

Lukas Eder

See Also:

MockConnection

Method Summary

Modifier and Type	Method and Description
MockResult[]	execute(MockExecuteContext ctx) Execution callback for a JDBC query execution.

Method Detail

execute

MockResult[] execute(MockExecuteContext ctx)
              throws java.sql.SQLException

Execution callback for a JDBC query execution.

This callback will be called by MockStatement upon the various statement execution methods. These include:

• Statement.execute(String)
• Statement.execute(String, int)
• Statement.execute(String, int[])
• Statement.execute(String, String[])
• Statement.executeBatch()
• Statement.executeQuery(String)
• Statement.executeUpdate(String)
• Statement.executeUpdate(String, int)
• Statement.executeUpdate(String, int[])
• Statement.executeUpdate(String, String[])
• PreparedStatement.execute()
• PreparedStatement.executeQuery()
• PreparedStatement.executeUpdate()

The various execution modes are unified into this simple method. Implementations should adhere to this contract:

• MockStatement does not distinguish between "static" and "prepared" statements. However, a non-empty MockExecuteContext.bindings() is a strong indicator for a PreparedStatement.
• MockStatement does not distinguish between "batch" and "single" statements. However...
  • A MockExecuteContext.batchSQL() with more than one SQL string is a strong indicator for a "multi-batch statement", as understood by jOOQ's DSLContext.batch(Query...).
  • A MockExecuteContext.batchBindings() with more than one bind variable array is a strong indicator for a "single-batch statement", as understood by jOOQ's DSLContext.batch(Query).
• It is recommended to return as many MockResult objects as batch executions. In other words, you should guarantee that:

   int multiSize = context.getBatchSQL().length;
   int singleSize = context.getBatchBindings().length;
   assertEquals(result.length, Math.max(multiSize, singleSize))
   

  This holds true also for non-batch executions (where both sizes are equal to 1)

• You may also return more than one result for non-batch executions. This is useful for procedure calls with several result sets.
  • In JDBC, such additional result sets can be obtained with Statement.getMoreResults().
  • In jOOQ, such additional result sets can be obtained with ResultQuery.fetchMany()
• If generated keys (Statement.RETURN_GENERATED_KEYS) are requested from this execution, you can also add MockResult.data to your result, in addition to the affected MockResult.rows. The relevant flag is passed from MockStatement to any of these properties:
  • MockExecuteContext.autoGeneratedKeys()
  • MockExecuteContext.columnIndexes()
  • MockExecuteContext.columnNames()
• OUT parameters from stored procedures are generated from the first MockResult's first Record. If OUT parameters are requested, implementors must ensure the presence of such a Record.

Parameters:

ctx - The execution context.

Returns:

The execution results. This should be non-null and non-empty, as every execution is expected to return at least one result.

Throws:

java.sql.SQLException - A SQLException that is passed through to jOOQ.