All Downloads are FREE. Search and download functionalities are using the official Maven repository.

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

The newest version!
/*
 * Copyright (c) 2009-2016, Data Geekery GmbH (http://www.datageekery.com)
 * All rights reserved.
 *
 * 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
 * ASL 2.0 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. *

* 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 (see the {@link #execute(MockExecuteContext)} * method). 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, rather than implementing your test * database inside of a {@link 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 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. This should be non-null and non-empty, as * every execution is expected to return at least one result. * @throws SQLException A SQLException that is passed through * to jOOQ. */ MockResult[] execute(MockExecuteContext ctx) throws SQLException; }




© 2015 - 2024 Weber Informatics LLC | Privacy Policy