On May 19, 2011, at 4:02 PM, Faheem Mitha wrote:
> Hi Michael,
>
> Thanks for the reply.
>
> On Thu, 19 May 2011 10:59:18 -0400, Michael Bayer <[email protected]>
> wrote:
>
>> I'm sure I mentioned earlier, one of the reasons you're finding this
>> difficult is because of this type of pattern, where you're calling
>> mapper() and Table at a different scope than where you make your
>> classes i.e. within a callable versus module level. At the very
>> least a function like make_tables() would ensure that its internal
>> implementation is called only once, such as:
>
>> _table_dict = None
>> def make_tables():
>> global _table_dict
>> if _table_dict is not None:
>> return _table_dict
>> _table_dict = {.... }
>
>> otherwise, you're creating new MetaData objects each time,
>> rebuilding a who= le new set of Tables in it each time, i.e. its a
>> total mess. Engine, Session registry, MetaData, your set of classes
>> and their mappers, these should all be global objects, created once
>> per application. If you want to use functions to initiate their
>> existence that is fine but you should be maintaining singleton
>> behavior in any case.
>
> You make good points. This certainly makes sense if I am only dealing
> with one set of database tables at a time. However, I'm working with
> multiple datasets, sometimes within a single Python script. So I guess
> some extra "wipe the slate clean" stuff when switching between
> different datasets is needed here.
Dont wipe anything clean - keep the state of each set of stuff separate. A
global dictionary perhaps, with an record inside for each configuration.
There's also not a use case for the same classes to be mapped to different
Table objects each time - the classes are designed to be mapped to a particular
table structure and Table+MetaData only represent that structure, nothing else.
If you're just switching between database backends, that switching occurs by
using a different Engine and perhaps a different Session registry.
>
> A couple of comments/questions.
>
> I see you are using _table_dict as an indicator. I'm not sure what
>
> _table_dict = {.... }
>
> is intended to indicate. Do you just mean initialize _table_dict with
> some non-None value before proceeding with the function?
"..." means you as the programmer would put here whatever it is you need to
keep track of.
>
> So if I am switching data sets, I guess I would need to recreate the
> tables, presumably by creating a new MetaData. Since the classes
> don't change, they don't need to be removed. So, would it sufice to
> have
I think you should consider the classes + mappers + tables + metadata to be a
single fixed structure. That's how it was designed to work - it's decoupled
from an actual database connection.
--
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.
