zam0th

1. db link спасет отца российской демократии, даже если хибернейт этого не умеет.

не знаю, как сейчас с дб-линками (в оракле?), а лет 6 назад их ограничения бесили

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

1 - в рамках одной hibernateовской сессии было бы неправильно работать с разными data sources, всё-таки это не транзакционный менеджер, чтобы давать какие-то гарантии корректности такой работы

2 - предположим, что есть hibernate.1.cfg.xml и hibernate.2.cfg.xml, которые описывают маппинги одних и тех же java-классов на таблицы разные datasources.
ты пробовал дерево, полученное в первой сессии, добавить во вторую сессию "в лоб"? я к тому, что, может, и без "перегоняний" можно обойтись?

2 не связано с хибернейтом :). вернее связано не только с ним. мне бы хотелось общее решение.

зы. я юзаю аннотации, и в них имхо нельзя один и тот же класс отобразить на разные структуры.

я почему-то подумал, что ты тоже из "аннотатчиков" ...

отговаривать не буду, но как бы в обсуждаемом контексте видны преимущества гибкости xml-based мэппингов над аннотациями

для копирования стоит попробовать commons beanutils. или не подходит по идейным соображениям?

можно ли хмл маппинги менять "на лету"? в рантайме я имею ввиду?

мне нужно не копирование, а трансформация одного дерева в другое (где классы и проперти в общем случае разные)

а никак без их изменения не обойтись?

теоретически задача решаема, потому что эти xml можно грузить как ресурсы (по крайней мере я так всегда делал), а это значит, что в class-loader'е, который отвечает за их "поставку", можно сделать всё, что захочется.
для решения, удобного на практике, наверное, требуется менее больная фантазия

а что касается универсального маппинга для трансформации объектов, то даже допуская наличие библиотек, могу сказать, что затея странная, т.к. настройка таких маппингов соразмерима по трудоёмкости с обычным тупым программированием серии вызовов setA(that.getB()), c = new D() и т.п.

ну если подумать о гетерогенных системах, то резон затеи сразу станет понятным ;)

так а в чём эта гетерогенность заключается и почему она вынуждает менять маппинги на лету вместо того, чтобы предусмотреть маппинги заранее?

я про деревья объектов :). про маппинги фишка типа того: есть разные бд с разным дизайном. но инфа по смыслу схожая. я хочу как-нить так замапить по уму (и при этом не ебать се моск онтологиями и прочей лжепоебней из датамайнинга), чтобы не плодить кучу энтитей, а иметь одну модель, по которой я бы смог без рестарта доставать хибернейтом инфу из любой базы. возможно придется расширять javax.persistence своими аннотациями, ибо xml это таки злоезло :).

ok, примерно наклёвывается понимание

1) я, конечно, тоже тот ещё любитель что-нибудь освоить, построив по пути велосипед с коляской, но xml имхо - сильно проще, чем любое функциональное расширение не-своей библиотеки

потом, нет гарантий, что под выбранную структуру модели на уровне hibernate не найдётся потом такая структура БД всё с той же "по смыслу похожей информацией", которую только лишь маппингами не подцепить

2) БД на то и БД, что в них бывают view, а в некоторых ещё и бывают triggers "instead of", если хочется обновлять данные через view, - т.о. задачу можно решить "штатными" средствами проадаптировав разные модели на уровне БД под то, что ожидается на уровне hibernate

1) гарантий конечно же нет. поэтому я и хочу некий универсальный способ :). класслоадеры имхо это зло и не выход, а в противном случае хмл маппинги ничем от аннотаций не отличаются
2) view не бывают :). в этом-то и проблема. конечно view было бы панацеей, но далеко не всегда их можно создать.

1) да я вроде написал как без класслоадера - через потомок Configuration. а xml-маппинги тем и хороши, что один и тот же бин можно замаппить как хочется, создавая разный xml в каждом случае

2) жаль, что такие БД ;-)

1) как же я ненавижу хмл :))))))))))))))))))))
2) угу мне тоже жаль :(. не все в мире идет так как нам хочется тт...

практически, я бы менял маппинги, скорее всего, так:
отнаследовался бы от org.hibernate.cfg.Configuration и переопределил бы методы addResource, addInputStream - чтобы они поставляли нужный мне контент в зависимости от доп. параметров


а дальше фантазия может подсказать хоть velocity-процессинг, генерирующий маппинги ;-)

вот я хотел примерно то же самое замутить только аннотациями :)))). походу таки придется наступить себе на что-то ;) и юзать хмл...

а ты-то тут че делаешь :))))))))

бляяяяяяяяяяя, я ж хотел в камьюнити по джаве запостить о.О

я тоже почему-то об этом подумал, но потом ... в-общем, поленился на это засомневаться :D