Cóż, można to zrobić na kilka sposobów i zależy to od struktury Twojej aplikacji. Oto najbardziej podstawowy sposób:
meta = MetaData(schema="client1")
Jeśli sposób, w jaki Twoja aplikacja działa, to jeden „klient” na raz w całej aplikacji, gotowe.
Ale to, co może być w tym nie tak, to to, że każda tabela z tych metadanych znajduje się w tym schemacie. Jeśli chcesz, aby jedna aplikacja obsługiwała jednocześnie wielu klientów (zwykle co oznacza „wielodostępny”), byłoby to nieporęczne, ponieważ musiałbyś utworzyć kopię MetaData i skopiować wszystkie mapowania dla każdego klienta. Takie podejście można wykonać, jeśli naprawdę chcesz, sposób, w jaki działa, to dostęp do każdego klienta za pomocą określonej zmapowanej klasy, takiej jak:
client1_foo = Client1Foo()
w takim przypadku pracowałbyś z przepisem „nazwa encji” na http://www.sqlalchemy.org/trac/wiki/UsageRecipes/EntityName w połączeniu z sometable.tometadata() (patrz http://docs.sqlalchemy.org/en/latest/core/metadata.html#sqlalchemy.schema.Table.tometadata).
Załóżmy więc, że tak naprawdę działa wielu klientów w aplikacji, ale tylko jeden na wątek. Właściwie najłatwiejszym sposobem na zrobienie tego w Postgresql byłoby ustawienie ścieżki wyszukiwania, gdy zaczynasz pracę z połączeniem:
# start request
# new session
sess = Session()
# set the search path
sess.execute("SET search_path TO client1")
# do stuff with session
# close it. if you're using connection pooling, the
# search path is still set up there, so you might want to
# revert it first
sess.close()
Ostatecznym podejściem byłoby nadpisanie kompilatora za pomocą rozszerzenia @compiles, aby umieścić nazwę „schematu” w instrukcjach. Jest to wykonalne, ale byłoby to trudne, ponieważ nie ma spójnego haka dla każdego miejsca, w którym generowana jest „Tabela”. Najlepszym rozwiązaniem jest prawdopodobnie ustawienie ścieżki wyszukiwania dla każdego żądania.
