class AbstractConcreteBase(ConcreteBase):
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))
.AbstractConcreteBase
have been reworked to support relationships established directly
on the abstract base, without any special configurational steps.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 |