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.

Reply via email to