On Oct 13, 2010, at 3:59 AM, Eskil Andréen wrote:
> Hello!
>
>
> class A(Base):
> __tablename__ = 'table_a'
> __table_args__ = {'schema':'schema_a'}
> id = Column(Integer, primary_key=True)
>
> class B(Base):
> __tablename__ = 'table_b'
> __table_args__ = {'schema':'schema_b'}
> id = Column('ID', Integer, primary_key=True)
> a_id = Column('A_ID', Integer, ForeignKey('schema_a.table_a.id'))
> c_id = Column('C_ID', Integer, ForeignKey('schema_c.table_c.id'))
>
> a = relation("A", backref=backref('bs'))
> b = relation("C")
>
> class C(Base):
> __tablename__ = 'table_c'
> __table_args__ = {'schema': 'schema_c'}
> id = Column(Integer, primary_key=True)
>
> def do_business_logic():
> # A bunch of logic that will use A, B and C.
>
> def run_functional_test():
> # First, set up an in memory DB fixture
> engine = create_engine('sqlite://', echo=True)
> NewBase = declarative_base()
> strip_schema_from_model(NewBase)
> NewBase.metadata.create_all(engine)
If it were me I'd probably have the declaratives set up entirely after some
global variable has been declared, so that all the constructs that call upon
schema like ForeginKey and __table_args__ can check this first (and I would
make a ForeignKey wrapper that does this automatically, as well as a
declarative base that handles __table_args__). The usual way of running
unittest or nose makes this possible since the test classes are imported first.
Otherwise, the ForeignKey presence makes everything tricky here. I'd probably
try to surgically alter all the Table objects, actually. But I'd never be
comfortable with it.
Rewriting the whole model as you're considering is ....sort of an option,
though i think ultimately has some major roadblocks...you don't want to
regenerate your classes entirely, you'd want to use the same class so that all
your methods and non-orm attributes are preserved, and at that point you run
into the declarative munging of columns and classes and such, all of which is
why the classical approach of "mapper()", or using declarative with __table__,
still has its advantages (I've been using the approach at
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/NamingConventions , which
seems to be the perfect blend).
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
