Цитата:
Сообщение от
Kashesh
Да я знаю, что можно вручную в коде сопоставить все поля и все. Но я хочу сделать универсально, вдруг добавятся еще поля и тд.. те получив на входе fieldId custTable, на выходе иметь fieldId vendTable
А не боитесь получить кучу проблем за счет "универсального" решения? Мне это напоминает использование buf2buf() для создания новых записей на базе существующих (периодически встречается такое) - поначалу кажется, что проще дернуть универсальный метод, чем перечислять все поля, а потом оказывается, что копировать-то надо вовсе и не все подряд, а "все, кроме..." - и далее идет длинный список полей-исключений. В стандартном приложении везде, где идет инициализация полей одной таблицы по значениям полей другой, эти поля явно перечислены, потому что
- такой механизм не надо править каждый раз, пополняя список полей-исключений, когда кто-то где-то добавил новое поле; если добавил - сам должен подумать о его копировании в другую таблицу;
- заставляет разработчиков думать головой на счет копирования каждого отдельного поля;
- дает возможность дернуть какой-нить обработчик изменения значения поля и подтянуть значения связанных полей;
- в связи с предыдущим пунктом дает возможность копировать поля в осмысленной последовательности, чтобы подтягиваемые связанные значения полей не перезатирали то, что прежде скопировано из поля таблицы.
Цитата:
Сообщение от
AndyD
Заведите свой собственный мап, в котором будут перечислены поля для синхронизации и сделайте что-то типа такого
...
Блок try-catch нужен для случаев отсутствия ссылок на поля в таблицах
Есть серьезное подозрение, что такой код нельзя будет использовать внутри транзакций, поскольку в них, как известно, отрабатывает не ближайший к месту возникновения исключения блок catch, а первый блок catch
вне транзакции.
PS. Есть такой класс MappingsInfo_RU, позволяющий для указанного Map и таблицы по названию поля Map получить код соотв. поля таблицы. Единственный косяк в нем - это использование в методе findMappingTreeNode() метода infolog.getNode() вместо обычного TreeNode::findNode(). Из-за этого и соотв. TreeNode, и затем TreeNodeIterator создаются на клиенте, что приводит при использовании класса на сервере к дикому трафику, тормозам и росту отжираемой памяти (может, уже и исправили этот кусок). А так, если создать, как советовали, свой Map и затем получить с помощью указанного класса данные по двум связанным через Map таблицам, то можно пробежаться по полученным Map'ам (на этот раз - экземплярам класса-контейнера) и скопировать значения полей, не рискуя "случайно" нарваться на поле Map, для которого в одной из таблиц нет отображения.