Dimitris Theodorou <[email protected]> wrote:
> Hi,
>
> I am looking to retrieving the pure python class that participates in a
> mapping. I would like to do this **after** the mapping took place and
> modified/extended the class' attributes.
>
> For instance, with this code
> class Thing(object):
> def __init__(self, id=None, name=None):
> self.id = id
> self.name = name
>
> def do_something(): pass
>
> things = Table(
> "things",
> metadata,
> Column("id", Integer, primary_key=True),
> Column("name", String)
> )
>
> mapper(Thing, things)
>
> After the mapper is called, it looks like the original class is modified
> beyond repair. By this I mean it is no longer possible to consider it a pure
> class that can be used for OO tasks, such as inheriting from it to inherit
> behavior.
a class that is mapped may be used as the base for new classes. There’s no
issue with that, it may be subclassed freely.
> Instead, a table is now directly associated with it and inheriting from it
> will either cause problems
such as?
> or create a 2nd table,
that is not true at all; if the class is classically mapped, tables are never
created. If the class is mapped using Declarative, the subclass will only
produce a new Table object if the subclass has a __tablename__ attribute,
otherwise the subclass is mapped using single-table inheritance.
> and will bring all the sql alchemy baggage with it (validators,
> relationships, etc.)
the ORM’s contract of use is that it instruments classes so that they can be
transparently mapped. If you didn’t want that, then you’d need to define some
entirely alternate way of referring to the state of an object. Using Core is
one way to go, or if you truly wanted some kind of alternate “package” where
the state of objects were kept, the entire system of class mapping can be
redefined completely. There’s likely not much rationale for this but take a
look at examples/custom_attributes/custom_management.py for the start of this
system.
>
> I would like to access the pure 'Thing" class as it stands before the call to
> mapper().
without alternate instrumentation, the mapping process can only be reversed by
calling clear_mappers(), however due to the complexity of achieving this on a
per-class basis, only a “full teardown” of all mappings is provided at this
time.
> The use-case is basically that I want to inherit behavior of the ORM class,
> but behavior only.
I’m not sure what mapper() does to a class other than change its behavior :)
you’d like attributes to be referred to table columns, you’d like relationships
and backrefs, these are behaviors. It doesn’t make sense to create a subclass
of this and not inherit these behaviors.
> I possibly want to map the inherited subclass to a *different* table.
that is fully possible, simply map it!
mapper(MySubClass, some_new_table)
it is likely appropriate to consider it as concrete table inheritance, in which
case this can be a more formal assocaition:
mapper(MySubClass, some_new_table, inherits=MySuperClass, concrete=True)
>
>
> So I have "copies" of my original items that reside in different tables, but
> they 1) share all behavior and 2) share a copy of *almost* all sql alchemy
> descriptors/behavior. Now the example above may look cute, but in reality if
> we are talking large classes with relationships, the @declared_attrs
@declared_attr? I thought we were using classical mapping? Declarative has
more of an impact on the class’ behavior at the class level that needs to be
considered.
>
> Having to split all my ORM classes into "behavior" and "mapping" logic
> results in fragmented code, when it looks like it should belongs together.
> I've also seen this recipe
> https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/EntityName, which I
> think is even worse in that regard.
>
> Could this be supported?
without more specifics, “map a subclass to a different table” is all I can see
here and that has been supported since version 0.1.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.