I should have clarified, I am only using declarative. The classical mapping example I wrote to illustrate the "pure" class that I wanted to "extract" out of a declarative class, with the intent to inherit the plain python behavior but none of the sql alchemy attributes.
Thanks for bringing concrete inheritance to my attention, I think this does exactly that: inherit all non-sql alchemy attributes. On Thursday, January 15, 2015 at 9:39:50 PM UTC+1, Michael Bayer wrote: > > > > Dimitris Theodorou <[email protected] <javascript:>> 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.
