Thanks.
I do not want to clear all maps, in order not to have to remap some
classes that don't change.
I think (3) answers my needs. I have an app. which has a mode which
tells it with which of 2 DBs (with same schema) it is working . This
mode is not changed often.
If I understood this correctly, I don't really need to touch the
mappings at all since the tables remain the same, but just change the
connection.
I'll try it out.
On Nov 25, 5:25 pm, "Michael Bayer" <[EMAIL PROTECTED]> wrote:
> Moshe C. wrote:
>
> > How would I unmap a class ( so that I can map it to another table from
> > a parallel but distinct DB) ?
> > I can't seem to find the documentation for the Mapper object itself.
>
> > I may be going the wrong way about it.
> > I want to map the same class to tables in different databases at
> > different times.
> > Where is the recommended point to change the association? The mapper ?
> > The session?
>
> all classes can be unmapped using clear_mappers(). As for unmapping and
> remapping individual classes, we don't provide a public API for this since
> the general procedure is problematic - it wouldn't work for mapped classes
> where the mappers are related to other mappers (extremely common), and
> needing to unmap/remap classes as a matter of course, except for testing
> purposes, would perform very poorly and is generally a poor pattern of
> use.
>
> There's many ways to relate a single class to multiple tables at different
> times, and it mostly depends on what you're trying to do.
>
> Methods for this include:
>
> 1. querying against an alternate selectable, which relates to the original
> mapped table:
>
> sess.query(MyClass).select_from(some_select).all()
>
> 2. Using non_primary mappers. This allows a view to be produced against
> an alternate table but persistence is not supported:
>
> mapper(MyClass, someothertable, non_primary=True)
>
> 3. If you are merely looking to share the mapping among the same table as
> represented in multiple databases, rebinding the session to different
> engines will work for a "full table" approach, or the sharding API can be
> used for more of an "automatic" approach.
>
> 4. For a full-blown "persist the class in multiple tables" approach,
> earlier versions of SQLA supported a concept called "entity_name". this
> feature has been removed in 0.5 since it is essentially redundant against
> pure python techniques which integrate more nicely with 0.5s paradigms
> (I'm adding this to the Wiki now):
>
> from sqlalchemy import *
> from sqlalchemy.orm import *
>
> metadata = MetaData(create_engine('sqlite://', echo=True))
> t1 = Table('t1', metadata, Column('id', Integer, primary_key=True))
> t2 = Table('t2', metadata, Column('id', Integer, primary_key=True))
> metadata.create_all()
>
> def map_class_to_some_table(cls, table, entity_name, **kw):
> newcls = type.__new__(type, entity_name, (cls, ), {})
> mapper(newcls, table, **kw)
> return newcls
>
> class Foo(object):
> pass
>
> T1Foo = map_class_to_some_table(Foo, t1, "T1Foo")
> T2Foo = map_class_to_some_table(Foo, t2, "T2Foo")
>
> sess = sessionmaker()()
>
> sess.add_all([T1Foo(), T1Foo(), T2Foo(), T1Foo()])
>
> print sess.query(T1Foo).all()
> print sess.query(T2Foo).all()
>
> the key assumption when using the "entity_name" approach is that the
> application must be explicitly aware of "which" mapped class its using.
> In previous versions, you didn't have to specify "entity_name" except when
> interacting with the Session. But since a mapping does affect class
> behavior, we've now moved towards the "specify it up front" pattern.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
