class documentation

class AbstractConcreteBase(ConcreteBase):

View In Hierarchy

A helper class for 'concrete' declarative mappings.

.AbstractConcreteBase will use the .polymorphic_union function automatically, against all tables mapped as a subclass to this class. The function is called via the __declare_last__() function, which is essentially a hook for the .after_configured event.

.AbstractConcreteBase does produce a mapped class for the base class, however it is not persisted to any table; it is instead mapped directly to the "polymorphic" selectable directly and is only used for selecting. Compare to .ConcreteBase, which does create a persisted table for the base class.

Note

The .AbstractConcreteBase class does not intend to set up the mapping for the base class until all the subclasses have been defined, as it needs to create a mapping against a selectable that will include all subclass tables. In order to achieve this, it waits for the mapper configuration event to occur, at which point it scans through all the configured subclasses and sets up a mapping that will query against all subclasses at once.

While this event is normally invoked automatically, in the case of .AbstractConcreteBase, it may be necessary to invoke it explicitly after all subclass mappings are defined, if the first operation is to be a query against this base class. To do so, invoke .configure_mappers once all the desired classes have been configured:

from sqlalchemy.orm import configure_mappers

configure_mappers()

See Also

_orm.configure_mappers

Example:

from sqlalchemy.ext.declarative import AbstractConcreteBase

class Employee(AbstractConcreteBase, Base):
    pass

class Manager(Employee):
    __tablename__ = 'manager'
    employee_id = Column(Integer, primary_key=True)
    name = Column(String(50))
    manager_data = Column(String(40))

    __mapper_args__ = {
        'polymorphic_identity':'manager',
        'concrete':True}

configure_mappers()

The abstract base class is handled by declarative in a special way; at class configuration time, it behaves like a declarative mixin or an __abstract__ base class. Once classes are configured and mappings are produced, it then gets mapped itself, but after all of its descendants. This is a very unique system of mapping not found in any other SQLAlchemy system.

Using this approach, we can specify columns and properties that will take place on mapped subclasses, in the way that we normally do as in :ref:`declarative_mixins`:

class Company(Base):
    __tablename__ = 'company'
    id = Column(Integer, primary_key=True)

class Employee(AbstractConcreteBase, Base):
    employee_id = Column(Integer, primary_key=True)

    @declared_attr
    def company_id(cls):
        return Column(ForeignKey('company.id'))

    @declared_attr
    def company(cls):
        return relationship("Company")

class Manager(Employee):
    __tablename__ = 'manager'

    name = Column(String(50))
    manager_data = Column(String(40))

    __mapper_args__ = {
        'polymorphic_identity':'manager',
        'concrete':True}

configure_mappers()

When we make use of our mappings however, both Manager and Employee will have an independently usable .company attribute:

session.query(Employee).filter(Employee.company.has(id=5))
Changed in version 1.0.0: - The mechanics of .AbstractConcreteBase have been reworked to support relationships established directly on the abstract base, without any special configurational steps.

See Also

.ConcreteBase

:ref:`concrete_inheritance`

Class Method __declare​_first__ Undocumented
Class Method ​_sa​_decl​_prepare​_nocascade Undocumented
Class Method ​_sa​_raise​_deferred​_config Undocumented
Class Variable __no​_table__ Undocumented

Inherited from ConcreteBase:

Class Method ​_create​_polymorphic​_union Undocumented
@classmethod
def __declare_first__(cls):
@classmethod
def _sa_decl_prepare_nocascade(cls):

Undocumented

@classmethod
def _sa_raise_deferred_config(cls):

Undocumented

__no_table__: bool =

Undocumented