org.jooq.tools.jdbc.MockDataProvider Maven / Gradle / Ivy

Go to download
Show more of this group Show more artifacts with this name
Show all versions of jooq Show documentation
There is a newer version: 3.19.18
/*
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 *
 * Other licenses:
 * -----------------------------------------------------------------------------
 * Commercial licenses for this work are available. These replace the above
 * Apache-2.0 license and offer limited warranties, support, maintenance, and
 * commercial database integrations.
 *
 * For more information, please visit: http://www.jooq.org/licenses
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 */
package org.jooq.tools.jdbc;

import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.Statement;

import org.jooq.DSLContext;
import org.jooq.Query;
import org.jooq.Record;
import org.jooq.ResultQuery;

/**
 * A data provider for mock query executions.
 * 
 * Supply this data provider to your {@link MockConnection} in order to globally
 * provide data for SQL statements.
 * 

 * Disclaimer: The general idea of mocking a JDBC connection with this
 * jOOQ API is to provide quick workarounds, injection points, etc. using a very
 * simple JDBC abstraction. It is NOT RECOMMENDED to emulate an entire database
 * (including complex state transitions, transactions, locking, etc.) using this
 * mock API. Once you have this requirement, please consider using an actual
 * database instead for integration testing (e.g. using
 * https://www.testcontainers.org),
 * rather than implementing your test database inside of a
 * MockDataProvider.
 * 

 * See {@link #execute(MockExecuteContext)} for more details.
 *
 * @author Lukas Eder
 * @see MockConnection
 */
@FunctionalInterface
public interface MockDataProvider {

    /**
     * Execution callback for a JDBC query execution.
     * 

     * This callback will be called by {@link MockStatement} upon the various
     * statement execution methods. These include:
     * 

     * 

     * {@link Statement#execute(String)}
     * {@link Statement#execute(String, int)}
     * {@link Statement#execute(String, int[])}
     * {@link Statement#execute(String, String[])}
     * {@link Statement#executeBatch()}
     * {@link Statement#executeQuery(String)}
     * {@link Statement#executeUpdate(String)}
     * {@link Statement#executeUpdate(String, int)}
     * {@link Statement#executeUpdate(String, int[])}
     * {@link Statement#executeUpdate(String, String[])}
     * {@link PreparedStatement#execute()}
     * {@link PreparedStatement#executeQuery()}
     * {@link 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
     * {@link MockExecuteContext#bindings()} is a strong indicator for a
     * {@link PreparedStatement}.
     * MockStatement does not distinguish between "batch" and
     * "single" statements. However...
     * 
     * A {@link MockExecuteContext#batchSQL()} with more than one SQL string
     * is a strong indicator for a "multi-batch statement", as understood by
     * jOOQ's {@link DSLContext#batch(Query...)}.
     * A {@link MockExecuteContext#batchBindings()} with more than one bind
     * variable array is a strong indicator for a "single-batch statement", as
     * understood by jOOQ's {@link 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
     * {@link Statement#getMoreResults()}.
     * In jOOQ, such additional result sets can be obtained with
     * {@link ResultQuery#fetchMany()}
     * 
     * 
     * If generated keys ({@link Statement#RETURN_GENERATED_KEYS}) are
     * requested from this execution, you can also add {@link MockResult#data}
     * to your first result, in addition to the affected
     * {@link MockResult#rows}. The relevant flag is passed from
     * MockStatement to any of these properties:
     * 
     * {@link MockExecuteContext#autoGeneratedKeys()}
     * {@link MockExecuteContext#columnIndexes()}
     * {@link MockExecuteContext#columnNames()}
     * 
     * 
     * OUT parameters from stored procedures are generated from the first
     * {@link MockResult}'s first {@link Record}. If OUT parameters are
     * requested, implementors must ensure the presence of such a
     * Record.
     * 
     *
     * @param ctx The execution context.
     * @return The execution results. If a null or an empty
     *         MockResult[] is returned, this has the same effect
     *         as returning
     *         new MockResult[] { new MockResult(-1, null) }
     * @throws SQLException A SQLException that is passed through
     *             to jOOQ.
     */
    MockResult[] execute(MockExecuteContext ctx) throws SQLException;
}