1

Тема: Entity with multiconection fields

Условия:
-  есть база на MSSQL. Ее изменить не полуиться - на нее заточен толстый клиент.
- есть база MySQL - там будут таблицы для дополнительный полей к сущностям.

Задача:
Нужно создать сущность поля которой мапятся на разные БД.

Есть например вариант несколько коннектов dbal и entity manager.
Но для EM - можно указать мапинг целиком для для бандла.

Тем более когда надо будет делать поиск по условию из двух баз, или какие-то изменения - то как сделать так чтобы один em передал управление другому em... В общем чуть думаю понятна. Я уже 4 дня ищу варианты.. тут на форуме искал - не нашел. В гугле то же подходящего кейса не нашел.

2

Re: Entity with multiconection fields

z-s пишет:

тут на форуме искал - не нашел. В гугле то же подходящего кейса не нашел

Это неудивительно. Доктрина такого не умеет, ну т. е. совсем.

z-s пишет:

можно указать мапинг целиком для для бандла

Ну, в общем-то, можно и для отдельной сущности или группы сущностей, просто конфигурация в таком случае становится более монструозной. Ну и работать с этим, прямо скажем, будет непросто — ведь вы для работы с сущностями все равно вызываете EM вручную, и вам придется вызывать не дефолтный, а именно нужный данной конкретной сущности.

В первую очередь стоит решить, зачем и насколько это нужно. Сущность, содержащая данные из двух баз, теряет атомарность и консистентность. При менеджменте, чтобы учесть все возможные расклады (например — в одной базе данные сущности сохранились, а вторая послала/легла, аналогично с выборками, когда одна из баз тупит/лежит/не имеет данных из-за того, что тупила/лежала когда их пытались сохранить или еще просто не успела синхронизироваться в случае репликации, потеря консистентности данных при конкуррентном сохранении — когда два клиента одновременно сохраняют данные одной сущности, но первая база в итоге сохраняет последней версию первого клиента, а вторая база — второго, и еще много других увлекательных вариаций) — вам придется нагородить целую неслабую надстройку над EM.
Т.е. если вам нужно не просто «собрать» данные в сущность для последующего отображения, но и сохранять такие сущности и изменения в них — ваш путь тяжел и я вам не завидую. А если менеджмент не нужен, то я бы отказался от Доктрины в данном случае и нарисовал свой репозитарий, который дергает данные из разных баз и гидрирует их в сущность(и). Доктрина для этого не нужна, ну разве что DBAL.

А если все же идти тяжелым путем... Наиболее логичным мне кажется было бы написать свой собственный EM в виде надстройки, и научить его работе с несколькими коннектами. Останется проблема — как указать, какое из полей сущности принадлежит какой из баз. Запилить собственную аннотацию несложно, но Доктрина о ней ничего знать не будет. В итоге в дополнение к EM возможно придется написать свой конфиг для сущности и его лоадер в EM, выглядит это все костыльно.

Либо просто собирать вашу «сущность» из двух доктриновских, каждая из которых замаплена на свой EM и коннект (паттерн facade). Тогда от Доктрины не требуется вообще ничего особенного, просто пишете репозитарий, который будет вам собирать/разбирать вашу сущность(и) из «деталек». И к этому репозитарию обращаетесь. Наиболее простой и лаконичный вариант. Но не подойдет, если вы активно пользуетесь связями в доктриновских сущностях, так как по связям из соседних сущностей будет дергаться не ваш гибрид, а именно «детальки».

Есть еще пара чисто костыльных вариантов — через события/lifecycle callbacks, но это уже для совсем отчаянных.

3

Re: Entity with multiconection fields

relo_san пишет:

Есть еще пара чисто костыльных вариантов — через события/lifecycle callbacks, но это уже для совсем отчаянных.

Они, кстати, такой вариант сами пропагандируют http://docs.doctrine-project.org/projec … b-odm.html

4

Re: Entity with multiconection fields

shurastik пишет:

Они, кстати, такой вариант сами пропагандируют

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

5

Re: Entity with multiconection fields

Спасибо за ответы.

Да - я так и думал что только капитальные костыли....  но все равно надо как-то будет расширять. Если найду элегантное решение -  отпишу сюда.

6

Re: Entity with multiconection fields

Да кстати если я запихну в свойство сущности другую сущность и потом буду работать с формами - мне придется отдельно обрабатывать обе сущности?

7

Re: Entity with multiconection fields

z-s пишет:

если я запихну в свойство сущности другую сущность и потом буду работать с формами - мне придется отдельно обрабатывать обе сущности?

Да. В случае создания новых — персистить придется обе сущности, каждую в своем EM. А в случае обновления придется в обеих EM вызывать flush для сохранения изменений. К форме это все имеет мало отношения, так как она просто обновит данные в обеих сущностях, и ничего более. Разумеется, персист и flush можно дергать для второй сущности как «вручную», так и костылями через события — суть одна, обрабатывать их придется отдельно.

8

Re: Entity with multiconection fields

немного расширяя тему: (уже в пределах одного соединения с одной базой)

Как реализовать динамический маппинг свойства - в частносит базу изменять нельзя - это условие остается.

Есть таблица А (ID ..... поле_типа ..... )

Есть таблица ТИП_1 (ID ...... )
Есть таблица ТИП_2(ID ...... )
...
Есть таблица ТИП_N (ID ...... )


Как реализовать сущность с доктриной2 (чтобы основная таблица оставалась А (в других например может быть вообще пусто)
и динамически в зависимости от значения поля "поле_типа" автоматом ввыбиралась нужная таблица?

понимаю что такая структура - не гуд. Но вот вариант реализации все равно нужен.

9

Re: Entity with multiconection fields

z-s пишет:

Как реализовать динамический маппинг свойства

На сколько я понимаю, он все же не совсем динамический, т.е. условия в обязательном порядке маппить и менять маппинг «на лету» я тут не вижу.

Из того, что сходу приходит в голову — Class Table Inheritance в Доктрине.
http://doctrine-orm.readthedocs.org/pro … nheritance
По идее, полностью должна подойти под вашу задачу.

10

Re: Entity with multiconection fields

Да все верно. Вариант с наследованием решает вопрос: Single Table Inheritance  http://odiszapc.ru/doctrine/inheritance … nheritance

Вот вариант с Class Table Inheritance - не очень понял. В частности я правильно понимаю что он дает возможность создать один объект напрямую со свойствами (без ссылок) - из нескольких таблиц?  (и если да - то насколько велика разница в производительсти если внутри одной СУБД - с одним em - делать объединение из разных БАЗ. (через точечную нотацию база.таблица)

11

Re: Entity with multiconection fields

z-s пишет:

В частности я правильно понимаю что он дает возможность создать один объект напрямую со свойствами (без ссылок) - из нескольких таблиц?

Да. Связь между таблицами управляется через специальное поле в основной таблице, значение которого определяет, на какую именно дочернюю таблицу будет маппиться основная.

z-s пишет:

насколько велика разница в производительсти если внутри одной СУБД - с одним em - делать объединение из разных БАЗ.

Учитывая редкость такого кейса, думаю вам это придется проверить самостоятельно. Создать такую схему, потестировать и сравнить производительность с обычной.
Плюс, скорее всего производительность такой выборки будет зависеть от типа БД.
Могу предположить, что разница в выборке отдельных записей по ключу будет минимальна либо ее вообще не будет, а вот разница в выборках серии строк может сильно отличаться, если БД не умеет (или Доктрина принципиально не поддерживает такую фичу) джойнить таблицы из разных баз. MSSQL, емнип, такое умеет, но это может быть запрещено администратором БД.

12

Re: Entity with multiconection fields

не не не - подобное поведение это совершенно точно для Single Table Inheritance... я же уточнял про Class Table Inheritance

13

Re: Entity with multiconection fields

z-s пишет:

подобное поведение это совершенно точно для Single Table Inheritance

Кагбэ нет. Single Table Inheritance — это когда таблица одна, а к какой сущности в PHP будут мапиться данные ее определенной строки — зависит от специального поля.

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

14

Re: Entity with multiconection fields

Во разъяснил!! спасиб. я как раз не мог въехать в CLASS вариант.

сингл - там все понятно в одной таблице куча сущностей собрана - и по значению из поля (жаль что только одного а не комплексно) определяется какая сущность... а там дальше уже можо каждую сущность по свойму расширять..



а вот класс - думал это просто ОДНА сущность в которой непосредственно ее значения (хранимые свойства) - т.е. без ссылок на другие сущности - из нескольких таблиц...
А получается что просто вариант полиморфизма - одна сущность но доп поля (прямо в ней же?) - добавляются только из одной из таблиц наследников. Можешь привести use case этого варианта?

15

Re: Entity with multiconection fields

z-s пишет:

одна сущность но доп поля

Не, не одна, но в остальном все верно. Сущности разные, но каждая замаплена и на общую и на свою таблицу. При этом например просто пользователи и админы могут жить в разных таблицах, но иметь общую сквозную идентификацию и какие-то поля. Хотя пример очень натянут, но других у меня вовсе нет.

z-s пишет:

Можешь привести use case этого варианта?

Сложный вопрос. Мне по крайней мере ни разу ничего подобного не нужно было. default/smile
Я даже теоретических задач не могу придумать, где эта схема была бы полезна и выгодна.
Как вариант — когда нужно формально объединить сущности, имеющие разный набор полей и объем данных. Такой себе продвинутый UNION. Но есть же Materialized View, который покрывает 99% таких задач.
Т.е. в принципе задачи для такой схемы есть, но есть как правило и более производительные способы их решения, особенно если это не MySQL.