On May 19, 2011, at 4:48 PM, Faheem Mitha wrote:

> Hi Michael,
> 
> On Thu, 19 May 2011 16:13:49 -0400, Michael Bayer <[email protected]> 
> wrote:
> 
>> Dont wipe anything clean - keep the state of each set of stuff
>> separate.  A global dictionary perhaps, with an record inside for
>> each configuration.
> 
> Could you elaborate on what you have in mind? The tables contain state
> reflecting the underlying database tables, right?

the state is only the names of the columns and their types.   not any data or 
database state.    

> Are you saying I
> should put all of classes + mappers + tables + metadata inside the
> value side of a dictionary? That could be pretty awkward to implement.

probably not, only whatever state it is that you need to "switch" - like if 
your thing is running with five different database backends at different times, 
you might put each Engine in this dictionary.   


> 
> Well, I do of course create a new engine when I switch from connecting
> with database1 to connecting with database2. When a new engine is
> created and a connection made, do the table objects automatically
> clear themselves of any old information? Maybe I'm just indulging in
> wishful thinking here...
> 
> Regardless, If I don't recreate the tables, the schema will be wrong,
> at least. I'm referring here to the schema field in tables for use
> with PostgreSQL, though I don't really understand what it does.

so you have this:

database 1:

schema1.table1
schema1.table2

database 2:

schema2.table1
schema2.table2

?

otherwise table1/table2 are identical in structure across database1, database2 
?   I'd try to get them all to have the same "schema" argument, actually, or 
modify the database user so that schema1, schema2 is in the user's search path:

http://www.postgresql.org/docs/current/static/ddl-schemas.html#DDL-SCHEMAS-PATH

this can be applied to the login with ALTER USER, or within just a single 
database session using SET search_path, in which case you'd use a connection 
event to set it up on each new connection.

then take "schema" out of the Table def.  its awkward
                             
> 
> Hmm. Meaning you should be able to transfer the whole thing between
> database connections?

yeah its only a description of structure, not the data.


-- 
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.

Reply via email to