Customizing DDL

In the preceding sections we’ve discussed a variety of schema constructsincluding Table,ForeignKeyConstraint,CheckConstraint, andSequence. Throughout, we’ve relied upon thecreate() and create_all() methods ofTable and MetaData inorder to issue data definition language (DDL) for all constructs. When issued,a pre-determined order of operations is invoked, and DDL to create each tableis created unconditionally including all constraints and other objectsassociated with it. For more complex scenarios where database-specific DDL isrequired, SQLAlchemy offers two techniques which can be used to add any DDLbased on any condition, either accompanying the standard generation of tablesor by itself.

Custom DDL

Custom DDL phrases are most easily achieved using theDDL construct. This construct works like all theother DDL elements except it accepts a string which is the text to be emitted:

  1. event.listen(
  2. metadata,
  3. "after_create",
  4. DDL("ALTER TABLE users ADD CONSTRAINT "
  5. "cst_user_name_length "
  6. " CHECK (length(user_name) >= 8)")
  7. )

A more comprehensive method of creating libraries of DDL constructs is to usecustom compilation - see Custom SQL Constructs and Compilation Extension fordetails.

Controlling DDL Sequences

The DDL construct introduced previously also has theability to be invoked conditionally based on inspection of thedatabase. This feature is available using the DDLElement.execute_if()method. For example, if we wanted to create a trigger but only onthe PostgreSQL backend, we could invoke this as:

  1. mytable = Table(
  2. 'mytable', metadata,
  3. Column('id', Integer, primary_key=True),
  4. Column('data', String(50))
  5. )
  6.  
  7. trigger = DDL(
  8. "CREATE TRIGGER dt_ins BEFORE INSERT ON mytable "
  9. "FOR EACH ROW BEGIN SET NEW.data='ins'; END"
  10. )
  11.  
  12. event.listen(
  13. mytable,
  14. 'after_create',
  15. trigger.execute_if(dialect='postgresql')
  16. )

The DDLElement.execute_if.dialect keyword also accepts a tupleof string dialect names:

  1. event.listen(
  2. mytable,
  3. "after_create",
  4. trigger.execute_if(dialect=('postgresql', 'mysql'))
  5. )
  6. event.listen(
  7. mytable,
  8. "before_drop",
  9. trigger.execute_if(dialect=('postgresql', 'mysql'))
  10. )

The DDLElement.execute_if() method can also work against a callablefunction that will receive the database connection in use. In theexample below, we use this to conditionally create a CHECK constraint,first looking within the PostgreSQL catalogs to see if it exists:

  1. def should_create(ddl, target, connection, **kw):
  2. row = connection.execute(
  3. "select conname from pg_constraint where conname='%s'" %
  4. ddl.element.name).scalar()
  5. return not bool(row)
  6.  
  7. def should_drop(ddl, target, connection, **kw):
  8. return not should_create(ddl, target, connection, **kw)
  9.  
  10. event.listen(
  11. users,
  12. "after_create",
  13. DDL(
  14. "ALTER TABLE users ADD CONSTRAINT "
  15. "cst_user_name_length CHECK (length(user_name) >= 8)"
  16. ).execute_if(callable_=should_create)
  17. )
  18. event.listen(
  19. users,
  20. "before_drop",
  21. DDL(
  22. "ALTER TABLE users DROP CONSTRAINT cst_user_name_length"
  23. ).execute_if(callable_=should_drop)
  24. )
  25.  
  26. sqlusers.create(engine)
  27. CREATE TABLE users (
  28. user_id SERIAL NOT NULL,
  29. user_name VARCHAR(40) NOT NULL,
  30. PRIMARY KEY (user_id)
  31. )
  32. select conname from pg_constraint where conname='cst_user_name_length'
  33. ALTER TABLE users ADD CONSTRAINT cst_user_name_length CHECK (length(user_name) >= 8)
  34. sqlusers.drop(engine)
  35. select conname from pg_constraint where conname='cst_user_name_length'
  36. ALTER TABLE users DROP CONSTRAINT cst_user_name_length
  37. DROP TABLE users

Using the built-in DDLElement Classes

The sqlalchemy.schema package contains SQL expression constructs thatprovide DDL expressions. For example, to produce a CREATE TABLE statement:

  1. from sqlalchemy.schema import CreateTable
  2. sqlengine.execute(CreateTable(mytable))
  3. CREATE TABLE mytable (
  4. col1 INTEGER,
  5. col2 INTEGER,
  6. col3 INTEGER,
  7. col4 INTEGER,
  8. col5 INTEGER,
  9. col6 INTEGER
  10. )

Above, the CreateTable construct works like anyother expression construct (such as select(), table.insert(), etc.).All of SQLAlchemy’s DDL oriented constructs are subclasses ofthe DDLElement base class; this is the base of all theobjects corresponding to CREATE and DROP as well as ALTER,not only in SQLAlchemy but in Alembic Migrations as well.A full reference of available constructs is in DDL Expression Constructs API.

User-defined DDL constructs may also be created as subclasses ofDDLElement itself. The documentation inCustom SQL Constructs and Compilation Extension has several examples of this.

The event-driven DDL system described in the previous sectionControlling DDL Sequences is available with other DDLElementobjects as well. However, when dealing with the built-in constructssuch as CreateIndex, CreateSequence, etc, the eventsystem is of limited use, as methods like Table.create() andMetaData.create_all() will invoke these constructs unconditionally.In a future SQLAlchemy release, the DDL event system including conditionalexecution will taken into account for built-in constructs that currentlyinvoke in all cases.

We can illustrate an event-drivenexample with the AddConstraint and DropConstraintconstructs, as the event-driven system will work for CHECK and UNIQUEconstraints, using these as we did in our previous example ofDDLElement.execute_if():

  1. def should_create(ddl, target, connection, **kw):
  2. row = connection.execute(
  3. "select conname from pg_constraint where conname='%s'" %
  4. ddl.element.name).scalar()
  5. return not bool(row)
  6.  
  7. def should_drop(ddl, target, connection, **kw):
  8. return not should_create(ddl, target, connection, **kw)
  9.  
  10. event.listen(
  11. users,
  12. "after_create",
  13. AddConstraint(constraint).execute_if(callable_=should_create)
  14. )
  15. event.listen(
  16. users,
  17. "before_drop",
  18. DropConstraint(constraint).execute_if(callable_=should_drop)
  19. )
  20.  
  21. sqlusers.create(engine)
  22. CREATE TABLE users (
  23. user_id SERIAL NOT NULL,
  24. user_name VARCHAR(40) NOT NULL,
  25. PRIMARY KEY (user_id)
  26. )
  27. select conname from pg_constraint where conname='cst_user_name_length'
  28. ALTER TABLE users ADD CONSTRAINT cst_user_name_length CHECK (length(user_name) >= 8)
  29. sqlusers.drop(engine)
  30. select conname from pg_constraint where conname='cst_user_name_length'
  31. ALTER TABLE users DROP CONSTRAINT cst_user_name_length
  32. DROP TABLE users

While the above example is against the built-in AddConstraintand DropConstraint objects, the main usefulness of DDL eventsfor now remains focused on the use of the DDL construct itself,as well as with user-defined subclasses of DDLElement that aren’talready part of the MetaData.create_all(), Table.create(),and corresponding “drop” processes.

DDL Expression Constructs API

  • sqlalchemy.schema.sorttables(_tables, skip_fn=None, extra_dependencies=None)
  • sort a collection of Table objects based on dependency.

This is a dependency-ordered sort which will emit Tableobjects such that they will follow their dependent Table objects.Tables are dependent on another based on the presence ofForeignKeyConstraint objects as well as explicit dependenciesadded by Table.add_is_dependent_on().

Warning

The sort_tables() function cannot by itself accommodateautomatic resolution of dependency cycles between tables, whichare usually caused by mutually dependent foreign key constraints.To resolve these cycles, either theForeignKeyConstraint.use_alter parameter may be appliedto those constraints, or use thesql.sort_tables_and_constraints() function which will breakout foreign key constraints involved in cycles separately.

  • Parameters
    • tables – a sequence of Table objects.

    • skip_fn – optional callable which will be passed aForeignKey object; if it returns True, thisconstraint will not be considered as a dependency. Note this isdifferent from the same parameter insort_tables_and_constraints(), which isinstead passed the owning ForeignKeyConstraint object.

    • extra_dependencies – a sequence of 2-tuples of tables which willalso be considered as dependent on each other.

See also

sort_tables_and_constraints()

MetaData.sorted_tables() - uses this function to sort

  • sqlalchemy.schema.sorttables_and_constraints(_tables, filter_fn=None, extra_dependencies=None)
  • sort a collection of Table / ForeignKeyConstraintobjects.

This is a dependency-ordered sort which will emit tuples of(Table, [ForeignKeyConstraint, …]) such that eachTable follows its dependent Table objects.Remaining ForeignKeyConstraint objects that are separate due todependency rules not satisfied by the sort are emitted afterwardsas (None, [ForeignKeyConstraint …]).

Tables are dependent on another based on the presence ofForeignKeyConstraint objects, explicit dependenciesadded by Table.add_is_dependent_on(), as well as dependenciesstated here using the skip_fnand/or extra_dependenciesparameters.

  • Parameters
    • tables – a sequence of Table objects.

    • filter_fn – optional callable which will be passed aForeignKeyConstraint object, and returns a value based onwhether this constraint should definitely be included or excluded asan inline constraint, or neither. If it returns False, the constraintwill definitely be included as a dependency that cannot be subjectto ALTER; if True, it will only be included as an ALTER result atthe end. Returning None means the constraint is included in thetable-based result unless it is detected as part of a dependency cycle.

    • extra_dependencies – a sequence of 2-tuples of tables which willalso be considered as dependent on each other.

New in version 1.0.0.

See also

sort_tables()

Base class for DDL expression constructs.

This class is the base for the general purpose DDL class,as well as the various create/drop clause constructs such asCreateTable, DropTable, AddConstraint,etc.

DDLElement integrates closely with SQLAlchemy events,introduced in Events. An instance of one isitself an event receiving callable:

  1. event.listen(
  2. users,
  3. 'after_create',
  4. AddConstraint(constraint).execute_if(dialect='postgresql')
  5. )

See also

DDL

DDLEvents

Events

Controlling DDL Sequences

  • call(target, bind, **kw)
  • Execute the DDL as a ddl_listener.

  • against(target)

  • Return a copy of this DDL against a specific schema item.

  • property bind

  • Returns the Engine or Connection towhich this Executable is bound, or None if none found.

This is a traversal which checks locally, thenchecks among the “from” clauses of associated objectsuntil a bound engine or connection is found.

Executes the DDL statement in isolation using the suppliedConnectable orConnectable assigned to the .bindproperty, if not supplied. If the DDL has a conditional oncriteria, it will be invoked with None as the event.

  1. - Parameters
  2. -
  3. -

bind – Optional, an Engine or Connection. If not supplied, a validConnectable must be present in the.bind property.

  1. -

target – Optional, defaults to None. The target SchemaItem for theexecute call. Will be passed to the on callable if any,and may also provide string expansion data for thestatement. See execute_at for more information.

  • executeat(_event_name, target)
  • Link execution of this DDL to the DDL lifecycle of a SchemaItem.

Deprecated since version 0.7: The DDLElement.execute_at() method is deprecated and will be removed in a future release. Please use the DDLEvents listener interface in conjunction with the DDLElement.execute_if() method.

Links this DDLElement to a Table or MetaData instance,executing it when that schema item is created or dropped. The DDLstatement will be executed using the same Connection and transactionalcontext as the Table create/drop itself. The .bind property ofthis statement is ignored.

  1. - Parameters
  2. -
  3. -

event – One of the events defined in the schema item’s .ddl_events;e.g. ‘before-create’, ‘after-create’, ‘before-drop’ or ‘after-drop’

  1. -

target – The Table or MetaData instance for which this DDLElement willbe associated with.

A DDLElement instance can be linked to any number of schema items.

execute_at builds on the append_ddl_listener interface ofMetaData and Table objects.

Caveat: Creating or dropping a Table in isolation will also triggerany DDL set to execute_at that Table’s MetaData. This may changein a future release.

  • executeif(_dialect=None, callable=None, _state=None)
  • Return a callable that will execute thisDDLElement conditionally.

Used to provide a wrapper for event listening:

  1. event.listen(
  2. metadata,
  3. 'before_create',
  4. DDL("my_ddl").execute_if(dialect='postgresql')
  5. )
  1. - Parameters
  2. -
  3. -

dialect

May be a string, tuple or a callablepredicate. If a string, it will be compared to the name of theexecuting database dialect:

  1. DDL('something').execute_if(dialect='postgresql')

If a tuple, specifies multiple dialect names:

  1. DDL('something').execute_if(dialect=('postgresql', 'mysql'))
  1. -

callable_

A callable, which will be invoked withfour positional arguments as well as optional keywordarguments:

ddl

This DDL element.

target

The Table or MetaData object which is thetarget of this event. May be None if the DDL is executedexplicitly.

bind

The Connection being used for DDL execution

tables

Optional keyword argument - a list of Table objects which are tobe created/ dropped within a MetaData.create_all() or drop_all()method call.

state

Optional keyword argument - will be the state argumentpassed to this function.

checkfirst

Keyword argument, will be True if the ‘checkfirst’ flag wasset during the call to create(), create_all(),drop(), drop_all().

If the callable returns a true value, the DDL statement will beexecuted.

  1. -

state – any value which will be passed to the callable_as the state keyword argument.

See also

DDLEvents

Events

A literal DDL statement.

Specifies literal SQL DDL to be executed by the database. DDL objectsfunction as DDL event listeners, and can be subscribed to those eventslisted in DDLEvents, using either Table orMetaData objects as targets. Basic templating support allowsa single DDL instance to handle repetitive tasks for multiple tables.

Examples:

  1. from sqlalchemy import event, DDL
  2.  
  3. tbl = Table('users', metadata, Column('uid', Integer))
  4. event.listen(tbl, 'before_create', DDL('DROP TRIGGER users_trigger'))
  5.  
  6. spow = DDL('ALTER TABLE %(table)s SET secretpowers TRUE')
  7. event.listen(tbl, 'after_create', spow.execute_if(dialect='somedb'))
  8.  
  9. drop_spow = DDL('ALTER TABLE users SET secretpowers FALSE')
  10. connection.execute(drop_spow)

When operating on Table events, the following statementstring substitutions are available:

  1. %(table)s - the Table name, with any required quoting applied
  2. %(schema)s - the schema name, with any required quoting applied
  3. %(fullname)s - the Table name including schema, quoted if needed

The DDL’s “context”, if any, will be combined with the standardsubstitutions noted above. Keys present in the context will overridethe standard substitutions.

  • init(statement, on=None, context=None, bind=None)
  • Create a DDL statement.

    • Parameters
      • statement

A string or unicode string to be executed. Statements will beprocessed with Python’s string formatting operator. See thecontext argument and the execute_at method.

A literal ‘%’ in a statement must be escaped as ‘%%’.

SQL bind parameters are not available in DDL statements.

  1. -

on

Deprecated since version 0.7: The DDL.on parameter is deprecated and will be removed in a future release. Please refer to DDLElement.execute_if().

Optional filtering criteria. May be a string, tuple or a callablepredicate. If a string, it will be compared to the name of theexecuting database dialect:

  1. DDL('something', on='postgresql')

If a tuple, specifies multiple dialect names:

  1. DDL('something', on=('postgresql', 'mysql'))

If a callable, it will be invoked with four positional argumentsas well as optional keyword arguments:

ddl

This DDL element.

event

The name of the event that has triggered this DDL, such as‘after-create’ Will be None if the DDL is executed explicitly.

target

The Table or MetaData object which is the target ofthis event. May be None if the DDL is executed explicitly.

connection

The Connection being used for DDL execution

tables

Optional keyword argument - a list of Table objects which are tobe created/ dropped within a MetaData.create_all() or drop_all()method call.

If the callable returns a true value, the DDL statement will beexecuted.

  1. -

context – Optional dictionary, defaults to None. These values will beavailable for use in string substitutions on the DDL statement.

  1. -

bind – Optional. A Connectable, used bydefault when execute() is invoked without a bind argument.

See also

DDLEvents

Events

Base class for DDL constructs that represent CREATE and DROP orequivalents.

The common theme of _CreateDropBase is a singleelement attribute which refers to the elementto be created or dropped.

Represent a CREATE TABLE statement.

  • init(element, on=None, bind=None, include_foreign_key_constraints=None)
  • Create a CreateTable construct.

    • Parameters
      • element – a Table that’s the subjectof the CREATE

      • on – See the description for ‘on’ in DDL.

      • bind – See the description for ‘bind’ in DDL.

      • include_foreign_key_constraints

optional sequence ofForeignKeyConstraint objects that will be includedinline within the CREATE construct; if omitted, all foreign keyconstraints that do not specify use_alter=True are included.

New in version 1.0.0.

Represent a DROP TABLE statement.

  • class sqlalchemy.schema.CreateColumn(element)
  • Bases: sqlalchemy.schema._DDLCompiles

Represent a Column as rendered in a CREATE TABLE statement,via the CreateTable construct.

This is provided to support custom column DDL within the generationof CREATE TABLE statements, by using thecompiler extension documented in Custom SQL Constructs and Compilation Extensionto extend CreateColumn.

Typical integration is to examine the incoming Columnobject, and to redirect compilation if a particular flag or conditionis found:

  1. from sqlalchemy import schema
  2. from sqlalchemy.ext.compiler import compiles
  3.  
  4. @compiles(schema.CreateColumn)
  5. def compile(element, compiler, **kw):
  6. column = element.element
  7.  
  8. if "special" not in column.info:
  9. return compiler.visit_create_column(element, **kw)
  10.  
  11. text = "%s SPECIAL DIRECTIVE %s" % (
  12. column.name,
  13. compiler.type_compiler.process(column.type)
  14. )
  15. default = compiler.get_column_default_string(column)
  16. if default is not None:
  17. text += " DEFAULT " + default
  18.  
  19. if not column.nullable:
  20. text += " NOT NULL"
  21.  
  22. if column.constraints:
  23. text += " ".join(
  24. compiler.process(const)
  25. for const in column.constraints)
  26. return text

The above construct can be applied to a Table as follows:

  1. from sqlalchemy import Table, Metadata, Column, Integer, String
  2. from sqlalchemy import schema
  3.  
  4. metadata = MetaData()
  5.  
  6. table = Table('mytable', MetaData(),
  7. Column('x', Integer, info={"special":True}, primary_key=True),
  8. Column('y', String(50)),
  9. Column('z', String(20), info={"special":True})
  10. )
  11.  
  12. metadata.create_all(conn)

Above, the directives we’ve added to the Column.info collectionwill be detected by our custom compilation scheme:

  1. CREATE TABLE mytable (
  2. x SPECIAL DIRECTIVE INTEGER NOT NULL,
  3. y VARCHAR(50),
  4. z SPECIAL DIRECTIVE VARCHAR(20),
  5. PRIMARY KEY (x)
  6. )

The CreateColumn construct can also be used to skip certaincolumns when producing a CREATE TABLE. This is accomplished bycreating a compilation rule that conditionally returns None.This is essentially how to produce the same effect as using thesystem=True argument on Column, which marks a columnas an implicitly-present “system” column.

For example, suppose we wish to produce a Table which skipsrendering of the PostgreSQL xmin column against the PostgreSQLbackend, but on other backends does render it, in anticipation of atriggered rule. A conditional compilation rule could skip this name onlyon PostgreSQL:

  1. from sqlalchemy.schema import CreateColumn
  2.  
  3. @compiles(CreateColumn, "postgresql")
  4. def skip_xmin(element, compiler, **kw):
  5. if element.element.name == 'xmin':
  6. return None
  7. else:
  8. return compiler.visit_create_column(element, **kw)
  9.  
  10.  
  11. my_table = Table('mytable', metadata,
  12. Column('id', Integer, primary_key=True),
  13. Column('xmin', Integer)
  14. )

Above, a CreateTable construct will generate a CREATE TABLEwhich only includes the id column in the string; the xmin columnwill be omitted, but only against the PostgreSQL backend.

Represent a CREATE SEQUENCE statement.

Represent a DROP SEQUENCE statement.

Represent a CREATE INDEX statement.

Represent a DROP INDEX statement.

Represent an ALTER TABLE ADD CONSTRAINT statement.

Represent an ALTER TABLE DROP CONSTRAINT statement.

Represent a CREATE SCHEMA statement.

The argument here is the string name of the schema.

  • init(name, quote=None, **kw)
  • Create a new CreateSchema construct.

Represent a DROP SCHEMA statement.

The argument here is the string name of the schema.

  • init(name, quote=None, cascade=False, **kw)
  • Create a new DropSchema construct.