Clear!
On Feb 8, 2011, at 10:21 PM, Michael Bayer wrote:
>
> On Feb 8, 2011, at 3:57 PM, Martijn Moeling wrote:
>
>> Clear, if all packages are in the same project that is......
>>
>> and what if in a.py I want to inherit some class mapped with b.py ....
>>
>> mixin does not allways work as a solution subclassing (DeclarativeMeta) is
>> an option, not sure
>>
>> Once I do a base=declarative_base(metadata=BaseB)
>>
>> every class x(Base) gets the Columns in BaseB to it ......?
>>
>> I have been setting up some tests and one way or the other I need to know
>> how Session is using Base, if I can have multiple declarative_base instances
>> and how Session relates to that.
>>
>>
>> Consider this:
>>
>> Base = Declarative_base()
>>
>> class a(Base):
>> ....
>> ....
>> ....
>>
>> def create_table(engine):
>> b=a()
>> metadata = b.metadata
>> metadata.create_all(engine)
>>
>> Base = None # IMPORTANT IS Sessionmaker using intropsection to find out
>> an instance of Declarative base?
>>
>> engine = ....
>> Session = SessionMaker(bind=engine)
>>
>> would this or a similar approach work?
>
> Session does not care about Base, nor does MetaData.
>
> The Base gives you this:
>
> class MyObject(Base):
> ...
> related = relationship("Related")
>
> the string "Related" is looked up in a dictionary inside of Base. The
> dictionary is called _decl_class_registry.
>
> MetaData gives you this:
>
> class MyObject(Base):
> ...
> related_id = Column(Integer, ForeignKey('related.id'))
>
> the string 'related.id' is broken into 'related' and 'id' and is looked up
> inside a dictionary inside of MetaData(). The dictionary is called
> "tables". There's some extra lookup helper mechanics surrounding this
> dictionary in 0.7 which is why we don't want you manipulating ".tables"
> directly.
>
> Those two registries are the *only* thing you get from a Base and a MetaData
> that is dependent on how many of them are in use. Neither is strictly
> needed. relationship() accepts the real class itself, i.e.
> relationship(Related). ForeignKey accepts a real column object, i.e.
> ForeignKey(related_table.c.id). The registries are strictly for the
> purpose of making it *easier* to organize table metadata and declarative
> classes without worrying about order of dependencies, allowing specification
> of related constructs via string name. Otherwise feel free to declare every
> single class and Table on its own Base and MetaData, it makes no difference.
>
> If you have multiple projects each with their own set of unrelated tables,
> there is no need to merge any Base or MetaData objects together. Simply call
> create_all() on each MetaData() object as needed. The namespaces remain
> entirely separate, as they should.
>
> If OTOH the multiple projects are linking to each other's tables and classes,
> then these projects have a dependency on each other. You should change them
> such that a common MetaData, and optionally a Base, can be specified from
> which they all make usage of - unless you can get away with not declaring any
> inter-package relationships or foreign keys with string names.
>
>
>
>
>
>
>
>
>
>>
>>
>> On Feb 8, 2011, at 9:12 PM, Michael Bayer wrote:
>>
>>> 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.
>>>
>>
>> --
>> 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.
