Python alembic.op 模块,inline_literal() 实例源码

我们从Python开源项目中,提取了以下7个代码示例,用于说明如何使用alembic.op.inline_literal()

项目:doorman    作者:mwielgoszewski    | 项目源码 | 文件源码
def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    query_tbl = sa.sql.table('query', sa.sql.column('platform', sa.String))
    pack_tbl = sa.sql.table('pack', sa.sql.column('platform', sa.String))
    op.execute(
        query_tbl.update() \
            .where(
                sa.or_(
                    query_tbl.c.platform==op.inline_literal('redhat,centos'),
                    query_tbl.c.platform==op.inline_literal('ubuntu'),
                )
            ).values({'platform': op.inline_literal('linux')})
    )
    op.execute(
        pack_tbl.update() \
            .where(
                sa.or_(
                    query_tbl.c.platform==op.inline_literal('redhat,centos'),
                    query_tbl.c.platform==op.inline_literal('ubuntu'),
                )
            ).values({'platform': op.inline_literal('linux')})
    )
    op.add_column('query', sa.Column('shard', sa.Integer(), nullable=True))
    ### end Alembic commands ###
项目:gnocchi    作者:gnocchixyz    | 项目源码 | 文件源码
def upgrade():
    op.add_column("resource_type", sa.Column('tablename', sa.String(18),
                                             nullable=True))

    resource_type = sa.Table(
        'resource_type', sa.MetaData(),
        sa.Column('name', sa.String(255), nullable=False),
        sa.Column('tablename', sa.String(18), nullable=True)
    )
    op.execute(resource_type.update().where(
        resource_type.c.name == "instance_network_interface"
    ).values({'tablename': op.inline_literal("'instance_net_int'")}))
    op.execute(resource_type.update().where(
        resource_type.c.name != "instance_network_interface"
    ).values({'tablename': resource_type.c.name}))

    op.alter_column("resource_type", "tablename", type_=sa.String(18),
                    nullable=False)
    op.create_unique_constraint("uniq_resource_type0tablename",
                                "resource_type", ["tablename"])
项目:idealoom    作者:conversence    | 项目源码 | 文件源码
def upgrade(pyramid_env):
    with context.begin_transaction():
        op.drop_column('facebook_post', 'post_type')
        op.drop_column('facebook_post', 'link_name')
        # Could also alter column, but this operation has limitations
        # (which we won't hit)
        op.drop_column('facebook_post', 'attachment')
        op.add_column('facebook_post', sa.Column('attachment_blob', sa.Binary))
        op.add_column('facebook_source', sa.Column('lower_bound', sa.DateTime))
        op.add_column('facebook_source', sa.Column('upper_bound', sa.DateTime))

        # Do stuff with the app's models here.
        from assembl import models as m
        db = m.get_session_maker()()
        with transaction.manager:
            # Also correct the spelling mistake in attachment model.
            a = m.Attachment.__table__
            db.execute(
                a.update().where(a.c.attachmentPurpose == op.inline_literal(
                                 'EMBEEDED_ATTACHMENT')).
                values(attachmentPurpose=op.inline_literal("EMBED_ATTACHMENT"))
            )
项目:idealoom    作者:conversence    | 项目源码 | 文件源码
def downgrade(pyramid_env):
    with context.begin_transaction():
        from assembl import models as m
        db = m.get_session_maker()()
        with transaction.manager:
            # Undo correcting of the spelling mistake in attachment model.
            a = m.Attachment.__table__
            db.execute(
                a.update().where(a.c.attachmentPurpose == op.inline_literal(
                                 'EMBED_ATTACHMENT')).
                values(attachmentPurpose=op.inline_literal(
                       "EMBEEDED_ATTACHMENT"))
            )

        op.drop_column('facebook_source', 'upper_bound')
        op.drop_column('facebook_source', 'lower_bound')
        op.drop_column('facebook_post', 'attachment_blob')
        op.add_column('facebook_post', sa.Column('post_type', sa.String(20)))
        op.add_column('facebook_post', sa.Column('link_name',
                      sa.Unicode(1024)))
        op.add_column('facebook_post', sa.Column('attachment',
                      sa.String(1024)))
项目:flasky    作者:RoseOu    | 项目源码 | 文件源码
def inline_literal(self, value, type_=None):
        """Produce an 'inline literal' expression, suitable for
        using in an INSERT, UPDATE, or DELETE statement.

        When using Alembic in "offline" mode, CRUD operations
        aren't compatible with SQLAlchemy's default behavior surrounding
        literal values,
        which is that they are converted into bound values and passed
        separately into the ``execute()`` method of the DBAPI cursor.
        An offline SQL
        script needs to have these rendered inline.  While it should
        always be noted that inline literal values are an **enormous**
        security hole in an application that handles untrusted input,
        a schema migration is not run in this context, so
        literals are safe to render inline, with the caveat that
        advanced types like dates may not be supported directly
        by SQLAlchemy.

        See :meth:`.execute` for an example usage of
        :meth:`.inline_literal`.

        :param value: The value to render.  Strings, integers, and simple
         numerics should be supported.   Other types like boolean,
         dates, etc. may or may not be supported yet by various
         backends.
        :param ``type_``: optional - a :class:`sqlalchemy.types.TypeEngine`
         subclass stating the type of this value.  In SQLAlchemy
         expressions, this is usually derived automatically
         from the Python type of the value itself, as well as
         based on the context in which the value is used.

        """
        return impl._literal_bindparam(None, value, type_=type_)
项目:pyetje    作者:rorlika    | 项目源码 | 文件源码
def inline_literal(self, value, type_=None):
        """Produce an 'inline literal' expression, suitable for
        using in an INSERT, UPDATE, or DELETE statement.

        When using Alembic in "offline" mode, CRUD operations
        aren't compatible with SQLAlchemy's default behavior surrounding
        literal values,
        which is that they are converted into bound values and passed
        separately into the ``execute()`` method of the DBAPI cursor.
        An offline SQL
        script needs to have these rendered inline.  While it should
        always be noted that inline literal values are an **enormous**
        security hole in an application that handles untrusted input,
        a schema migration is not run in this context, so
        literals are safe to render inline, with the caveat that
        advanced types like dates may not be supported directly
        by SQLAlchemy.

        See :meth:`.execute` for an example usage of
        :meth:`.inline_literal`.

        :param value: The value to render.  Strings, integers, and simple
         numerics should be supported.   Other types like boolean,
         dates, etc. may or may not be supported yet by various
         backends.
        :param ``type_``: optional - a :class:`sqlalchemy.types.TypeEngine`
         subclass stating the type of this value.  In SQLAlchemy
         expressions, this is usually derived automatically
         from the Python type of the value itself, as well as
         based on the context in which the value is used.

        """
        return impl._literal_bindparam(None, value, type_=type_)
项目:Callandtext    作者:iaora    | 项目源码 | 文件源码
def inline_literal(self, value, type_=None):
        """Produce an 'inline literal' expression, suitable for
        using in an INSERT, UPDATE, or DELETE statement.

        When using Alembic in "offline" mode, CRUD operations
        aren't compatible with SQLAlchemy's default behavior surrounding
        literal values,
        which is that they are converted into bound values and passed
        separately into the ``execute()`` method of the DBAPI cursor.
        An offline SQL
        script needs to have these rendered inline.  While it should
        always be noted that inline literal values are an **enormous**
        security hole in an application that handles untrusted input,
        a schema migration is not run in this context, so
        literals are safe to render inline, with the caveat that
        advanced types like dates may not be supported directly
        by SQLAlchemy.

        See :meth:`.execute` for an example usage of
        :meth:`.inline_literal`.

        The environment can also be configured to attempt to render
        "literal" values inline automatically, for those simple types
        that are supported by the dialect; see
        :paramref:`.EnvironmentContext.configure.literal_binds` for this
        more recently added feature.

        :param value: The value to render.  Strings, integers, and simple
         numerics should be supported.   Other types like boolean,
         dates, etc. may or may not be supported yet by various
         backends.
        :param ``type_``: optional - a :class:`sqlalchemy.types.TypeEngine`
         subclass stating the type of this value.  In SQLAlchemy
         expressions, this is usually derived automatically
         from the Python type of the value itself, as well as
         based on the context in which the value is used.

        .. seealso::

            :paramref:`.EnvironmentContext.configure.literal_binds`

        """
        return impl._literal_bindparam(None, value, type_=type_)