# createMissingTablesAndColumns

fun createMissingTablesAndColumns(vararg tables: Table, inBatch: Boolean = false, withLogs: Boolean = true)

### Deprecated

Execution of this function might lead to unpredictable state in the database if a failure occurs at any point. To prevent this, please use `MigrationUtils.statementsRequiredForDatabaseMigration()` with a third-party migration tool (e.g., Flyway). `MigrationUtils` is accessible with a dependency on `exposed-migration-jdbc`.

#### Replace with

    import org.jetbrains.exposed.v1.migration.jdbc.MigrationUtils

Content copied to clipboard

    MigrationUtils.statementsRequiredForDatabaseMigration(*tables, withLogs = withLogs)

Content copied to clipboard

This function should be used in cases when an easy-to-use auto-actualization of database schema is required. It creates any missing tables and, if possible, adds any missing columns for existing tables (for example, when columns are nullable or have default values).

Note: Some databases, like SQLite, only support `ALTER TABLE ADD COLUMN` syntax in very restricted cases, which may cause unexpected behavior when adding some missing columns. For more information, refer to the relevant documentation. For SQLite, see ALTER TABLE restrictions.

Also, if there is inconsistency between the database schema and table objects (for example, excessive or missing indices), then SQL statements to fix this will be logged at the INFO level.

By default, a description for each intermediate step, as well as its execution time, is logged at the INFO level. This can be disabled by setting withLogs to `false`.

Note: This functionality is reliant on retrieving JDBC metadata, which might be a bit slow. It is recommended to call this function only once at application startup and to provide all tables that need to be actualized.

Note: Execution of this function concurrently might lead to unpredictable state in the database due to non-transactional behavior of some DBMS when processing DDL statements (for example, MySQL) and metadata caches. To prevent such cases, it is advised to use any preferred "global" synchronization (via redis or memcached) or to use a lock based on synchronization with a dummy table.

#### See also

SchemaUtils.withDataBaseLock