On Jan 23, 2010, at 4:02 PM, Christoph Burgmer wrote: > Thanks for the quick reply. > > On Jan 23, 9:20 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: >> it seems like you're mixing two different ways to get at various databases. >> one is, theres a central database that can access other databases via >> schemas. great. the other is, you have connections to each database >> individually. also great. but your questions seem to indicate you're >> doing both at the same time - the need for "tables without the schemas" >> implies direct access to the remote databases, the need for "joins" implies >> via-schema access to them. you'd be better off picking one method and just >> sticking with it. once you do that you can decide how you'd like to broker >> statements to each database. bound-metadata-per-database is one, or just >> using a dispatching executor (for which one way is to use the ORM's Session >> object , just its execute() method in conjunction with its binds argument, >> or a similar approach). > > I am only using schemas as MySQL needs the exact address. I'd be happy > without it. SQLite can do without. I don't need any particular control > where my data lies. I'd only touch attached databases with reads, no > writes. If two tables with the same name come up, one will be ignored. > Basically like a global file system on databases. > > See my wish for several databases only as a need for easy extension. > Installing Package A will bring in A.db, installing Package B based on > A will add its own. Package B will then access A.db through Package > A's routines adding B.db for further data. > > I finally found the Session example (the link got broken), and while > it's simple, I lose the joins I might be happy to have later. > > Do you have a particular reason for advising an 'either or' solution?
if you need to issue "A join B", then you have to access A and B via the same conneciton, using some kind of schema/DBLINK type of system. If not, then you can rely upon some kind of "connection spec per table" scheme, which using individual bound MetaData objects per engine, each containing the full set of tables, would achieve. As far as your "pick one table with given name X and ignore the others" behavior that's some kind of registry logic you'd have to build yourself. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
