On Thu, 19 May 2011 16:57:14 -0400, Michael Bayer <mike...@zzzcomputing.com> wrote:
> On May 19, 2011, at 4:48 PM, Faheem Mitha wrote: >> Hi Michael, >> On Thu, 19 May 2011 16:13:49 -0400, Michael Bayer >> <mike...@zzzcomputing.com> 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. Ok. I see. I thought it contained data, since you can put data into it, and then sync with the database. >> 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 ? Unfortunately, that is not true. (So I guess just leaving the structure alone and switching dbs will not work.) There are 4 possible different database layouts. Also, there can be multiple schemas in each database. database 1: schema1.table1 schema1.table2 schema2.table1 schema2.table2 I still think nuking the whole thing when switching between datasets is my best bet. I'm actually a little surprised the thing works, considering I have such a poor idea what is going on. So, as regards nuking classes + mappers + tables + metadata. If this is possible, how would I accomplish it? Or feel free to suggest if you have better ideas. > 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. Yes, that's certainly an option. But that won't solve my problems by itself. See above. > then take "schema" out of the Table def. > its awkward That's true. >> Hmm. Meaning you should be able to transfer the whole thing between >> database connections? > yeah its only a description of structure, not the data. Ok. Regards, Faheem -- 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.
