org.jooq.AlterIndexStep 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.15
/*
 * 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
 *
 *  https://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: https://www.jooq.org/legal/licensing
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 *
 */
package org.jooq;

import static org.jooq.SQLDialect.*;
import static org.jooq.impl.DSL.*;

import java.util.*;

import org.jooq.impl.DSL;

import org.jetbrains.annotations.*;

/**
 * A step in the construction of the ALTER INDEX statement.
 * 
 * 
Referencing XYZ*Step types directly from client code
 * 
 * It is usually not recommended to reference any XYZ*Step types
 * directly from client code, or assign them to local variables. When writing
 * dynamic SQL, creating a statement's components dynamically, and passing them
 * to the DSL API statically is usually a better choice. See the manual's
 * section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.
 * 

 * Drawbacks of referencing the XYZ*Step types directly:
 * 

 * They're operating on mutable implementations (as of jOOQ 3.x)
 * They're less composable and not easy to get right when dynamic SQL gets
 * complex
 * They're less readable
 * They might have binary incompatible changes between minor releases
 * 
 */
@SuppressWarnings({ "unused" })
public interface AlterIndexStep {

    /**
     * Add the RENAME TO clause to the ALTER INDEX statement.
     * 
     * Note that in some databases, including MySQL and SQL Server, the index namespace
     * is tied to a table, not a schema. In those databases, it is recommended to call {@link
     * DSLContext#alterTable(String)} with {@link AlterTableStep#renameIndex(String)} instead.
     */
    @Support({ DERBY, H2, HSQLDB, MARIADB, MYSQL, POSTGRES })
    @NotNull @CheckReturnValue
    AlterIndexFinalStep renameTo(@Stringly.Name String renameTo);

    /**
     * Add the RENAME TO clause to the ALTER INDEX statement.
     * 

     * Note that in some databases, including MySQL and SQL Server, the index namespace
     * is tied to a table, not a schema. In those databases, it is recommended to call {@link
     * DSLContext#alterTable(String)} with {@link AlterTableStep#renameIndex(String)} instead.
     */
    @Support({ DERBY, H2, HSQLDB, MARIADB, MYSQL, POSTGRES })
    @NotNull @CheckReturnValue
    AlterIndexFinalStep renameTo(Name renameTo);

    /**
     * Add the RENAME TO clause to the ALTER INDEX statement.
     * 
     * Note that in some databases, including MySQL and SQL Server, the index namespace
     * is tied to a table, not a schema. In those databases, it is recommended to call {@link
     * DSLContext#alterTable(String)} with {@link AlterTableStep#renameIndex(String)} instead.
     */
    @Support({ DERBY, H2, HSQLDB, MARIADB, MYSQL, POSTGRES })
    @NotNull @CheckReturnValue
    AlterIndexFinalStep renameTo(Index renameTo);
}