Почему полезно иметь объект MetaData, который не привязан к движку в SQLAlchemy?

Question

Я пытаюсь понять поведение MySQL относительно объекта MetaData и объекта engine. Этот SO-ответ описывает MetaData как

набор определений таблиц

и engine как

диалект и детали подключения конкретной базы данных

Пока все хорошо.Но когда полезно разделить эти два?Разве определения таблиц не связаны с конкретной базой данных?

Answer 1

В SQLAlchemy 0.1 не было объекта "метаданных" - Engine был привязан непосредственно к каждому Table.Эта идея очень быстро устарела, отчасти потому, что люди хотели объявить свой объект Table до того, как они подключились, и появились «связанные метаданные».Затем произошел длительный период массового беспорядка.У людей была сверхтяжелая привычка (так как я велел им делать это таким образом), говорить что-то вроде:

table.insert().execute()

result = table.select().execute()

Т.е. без транзакций, каждый раз используя новое соединение.Тогда мы скажем: «ну, вы должны использовать транзакцию, вы должны быть более эффективными в отношении соединений», а затем мы в основном сказали бы им, что они должны переписать свое приложение, и мем «sqlalchemy имеет слишком много способов»взрывал, как воздушный шар

1007 * в то же время, пилоны и другие механизмы раннего WSGI были толкания трудно иметь несколько «приложений», работающих одновременно. - в некоторых случаях различные «пользователи» будет иметь свой собственный набортаблицы каждая в разных базах данных, вроде того.Более распространенными являются подходы горизонтального масштабирования, когда одни и те же таблицы находятся во многих базах данных.У меня есть приложение, которое имеет встроенную систему «репликации», в которой записи периодически копируются из «первичной» базы данных в базу данных «история», и метаданные таблицы там тоже являются общими.

Дело в том,во всех этих случаях пользователи приходили на SQLA, и их понимание вещей начиналось с «связанных метаданных».Блоги и учебники повсеместно использовали его.И большая часть этих пользователей должна была бы вырваться из этой системы и полностью запутаться, что существует весь этот «другой способ» работы.Таким образом, стало ясно, что система «связанных метаданных» была слишком жесткой по умолчанию.В идеале я бы хотел, чтобы я вообще никогда не реализовывал это, и я никогда не использую это сам.Вот почему документы для этого теперь помещены в один раздел, новые пользователи, которые только просматривают документы, которые по своей природе добавляют огромное бремя поддержки к списку рассылки, не находят его и не путаются.В самом разделе есть множество маркеров, объясняющих, когда и почему это сбивает с толку .Я предполагаю, что вы прочитали это в http://www.sqlalchemy.org/docs/core/schema.html#binding-metadata-to-an-engine-or-connection.

Answer 2

Фактически, определения таблиц не связаны с конкретной базой данных. Объект метаданных sqlalchemy и все присоединенные объекты (таблицы, столбцы, индексы и т. Д.) Определяют полностью абстрактную схему без ссылки на какую-либо конкретную базу данных. Движок - это три вещи: информация о соединении, диалект и пул соединений. Диалект является важной частью здесь, он определяет, как подключиться к конкретной базе данных, но, что более важно, в отношении вашего вопроса, он также определяет, как переводить объекты абстрактной схемы sqla (metadata et al) в команды sql , специфичные для эта база данных и драйвер .

Это разделение имеет несколько различных применений:

• Приложения могут определять свою схему на уровне модуля, создавая таблицы и метаданные при импорте модуля ... но не утруждая себя определением механизма, пока приложение на самом деле работает и работает (так как знает полный URL-адрес соединения и Обычно диалект требует чтения конфигурационного файла или получения ввода от пользователя).

• Вы можете иметь ситуацию с несколькими движками, привязанными к одному и тому же набору метаданных, например, к веб-приложению, где каждый пользователь / пароль подключается к базе данных со своими учетными данными (не то, что это эффективно, но иногда необходимо для в целях безопасности). Поскольку метаданные являются глобальным объектом, в этом случае не имеет смысла связывать их с конкретным механизмом.

• Это редко, но вы также можете иметь обратный случай, несколько экземпляров метаданных для одного механизма. Это может произойти, когда несколько подкомпонентов совместно используют одну и ту же базу данных, но используют разные имена таблиц. Кроме того, это может произойти при попытке сравнить текущую схему приложения в одном экземпляре метаданных с другим, что было отражено с сервера (например, для целей миграции схемы). Это строго не помешает вам привязать каждый из них к движку, но поможет продемонстрировать, как может быть полезно несколько метаданных или экземпляров движка.

Возможно, есть еще несколько вариантов использования, о которых я сейчас не могу думать, но это должно дать вам общее представление о том, почему они концептуально отделены друг от друга.