the idea is like this: myproject/ myproject/__init__.py myproject/meta.py myproject/somepackage/__init__.py myproject/somepackage/a.py myproject/someotherpackage/__init__.py myproject/someotherpackage/b.py
myproject/__init__.py: from myproject.somepackage import a from myproject.someotherpackage import b meta.py: Base = declarative_base() a.py: from myproject.meta import Base b.py: from myproject.meta import Base On Feb 8, 2011, at 2:25 PM, Martijn Moeling wrote: > Michael, > > Do you ever sleep? > > I am not sure I get your point. How do I set up a common "Base". > > I could do Base= Declarative_base() > > from a import A (or * not sure how this differs in this case) > from b import B (or *) > > If I do not declare Base in module "a" I get an Import Error on class > A(Base), the same for importing b. > > This gets even more complicated when Base should be build from classes > defined across modules. > > at the end there is one main.py importing all modules and this should be able > to define the "Main Base". > > Any suggestions on how to tackle this. I know have multiple modules and am > glueing everything together. This even gets more problematic with Inheritance. > > one solution could be.. > > from a import A, BaseA > from b import B, BaseB > > Base = declarative_base() > > metadata - BaseA.metadata + BaseB.metadata > metadata.create_all(engine) > > What I do not get is how the mapper is configured. Normally with declarative > Base it is not used in "Production fase" for as far as I can see..... > The mapper is part of the Class right? and session does not use Base at all? > but gets it when needed -> Session.query(A)..... ? > Or am I totally wrong on this? > > Can I something like this: > > from a import * (imports class A and the declarative_base BaseA) > > Base = declarative_base() > > class C(Base): > ....... > > BaseForB = declarative_base(metadata=BaseA) > class B(BaseForB) > > > Mixin classes are of type object so there is no issue since @declared_attr > etc works.... > > class D(Base,mixinclass) works without a Base at all so there is no Issue.... > > Am I right? in understanding your comments on my first mail in this topic? > > Martijn > > > > > > > > On Feb 8, 2011, at 7:46 PM, Michael Bayer wrote: > >> >> On Feb 8, 2011, at 1:19 PM, Martijn Moeling wrote: >> >>> Hi, >>> >>> I am having a small issue with multiple python modules and declarative... >>> >>> I might miss something but.... >>> >>> Consider: >>> >>> a.py: >>> >>> 8<------------------------------- >>> Base = declarative_base() >>> >>> class A(Base): >>> ... >>> 8<------------------------------- >>> >>> b.py >>> Base = declarative_base() >>> >>> class B(Base): >>> ... >>> 8<------------------------------- >>> >>> c.py >>> Base = declarative_base() >>> >>> class C(Base): >>> ... >>> 8<------------------------------- >>> >>> d.py >>> >>> Base = declarative_base() >>> >>> from A import * # imports base.... >>> from B import * # imports base.... >>> from C import * # imports base.... >>> >>> Class D1(Base) >>> ... >>> >>> Class D2(A) >>> ... >>> >>> >>> in d.py I want to create: >>> >>> def create_tables(engine): >>> metadata= Base.metadata >>> metadata.create_all(engine) >>> >>> >>> Is there any way to properly "add" the metadata from the imported modules >>> in d.py to the Base.metadata during the import......? >>> Think of modules a,b,c and d are together in a package and d is imported >>> with similar packages into something bigger.... >> >> Usually the convention is that all modules in an application share the same >> declarative base object (i.e. Base). If you wanted multiple Base objects >> but have them share a common MetaData, you can declare the MetaData up >> front, then create each Base using declarative_base(metadata=my_metadata). >> Otherwise if you're really looking to merge together multiple MetaData >> objects, that's not really in the API right now in a clean way, you'd >> perhaps call .tometadata() on each Table object but that's really not what I >> would do here - it copies the whole Table object and isn't really for a use >> case like this. If you can at least have a common MetaData object, or >> better a common Base object, that would be the best way to go. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To post to this group, send email to sqlalchemy@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. >> > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalchemy@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. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@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.
