Есть 2 сущности Product и Properties.
Товар и его свойства.
Периодически свойства товара меняются, но разные люди работают с разными, так сказать версиями товара.
Т.е. на складе есть товар версии1 со своими свойствами и товар версии2 со своими совйствами.
Для этого в Product и в Properties добавили поле version.
И разные люди должны при выборке "Покажи товар c ID=3, версии 1" и "Покажи товар с ID=3, версии 2", получить Product с соответствующими фильтрами.
Пока все было маленькое и использовали обычный SQL, все было хорошо. Просто в запрос добавлялся условие по версии, все работало.
Но теперь такое надо сделать в Hibernate.

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

Так вот, как в мапинг @ManyToOne для Properties, добавить условие, что версия Properties должна быть равна версии Product?




В запросе NamedQuery, легко добавляется параметр версия. Но при этом в список пропертей, попадают проперти от всех версий. Как туда тоже добавить фильтр по версии?

Да, забыл сказать. Envers хибернейтовский не канает, по самым разным причинам. Его уже рассматривали.

BlazkowiczУ вас есть некоторая бизнес-логика, связаная с версионностью структуры.
В чем глубинный смысл зашивать эту бизнес-логику в слой работы ORM, а не реализовать отдельным наружным слоем, оставив ORM лишь инструментом работы с моделью заданной БД?
Т.е. как это в чем смысл? Надо же хранить версии и работать с ними.

Petro123Blazkowicz,
+1
аффтра. Вы сказали, что раньше - работало. Покажите модель БД когда работало.

Оно не когда-то работало, оно и сейчас работает. Без хибернейта.
Но вот опять. Не надо обсуждать модель. Это не реальный пример, выдумка, фантазии... не знаю как еще это объяснить...
Пример привел просто чтобы показать техническую проблему, а не архитектуру.
Вопрос был не "как мне сделать версионность", а "как за мапить с доп условиями".
Зачем флудить, уходя в дебри не заданного вопроса?

Petro123Ищущий ЗнанияНадо же хранить версии и работать с ними.
вам не уйти от "сферического коня" по вашему определению.
- зачем хранить?
- как работать?
- почему именно версия товара? IMHO коряво выглядит этот термин.

Ну вы даете))
1. Как это зачем хранить? Ну вот бизнесу надо хранить версии... мне им сказать чтоб не хотели и выкинули базу за последние несколько лет с версиями?

2. Как работать вопрос не стоит. Уже работают и проблем с этим нет.

3. Может название и корявое, но отражает реальность. Это изменения свойств объекта во времени. Все привыкли называть это версиями. Не вижу тут никакой проблемы.

Petro123Ищущий Знанияа "как за мапить с доп условиями".
хибер маппит Реальную БД и таблицы.
Т.е. DAO зеркало БД.
А потом в сервисном слое подменяй свои версии объектов.
IMHO об этом тебе и было сказано.

Может конкретно описать, безо всяких заклинаний типа "сделай DAO в сервисе"?
Вы предлагаете извлекать связанные таблицы не хибернейтом, а руками?
Сначала выбирать товар, потом отдельно выбирать проперти к нему и руками их соединять, отказавшись от мапинга в хибернейте?

Petro123IMHO почти твоя модель, т.к. ты ничего не привёл кроме общих фраз:
Т.е. конкретный код, который я привел это "ничего" ?
Он полностью описывает ситуацию. Там всего 2 таблицы с двумя полями.

Ну ладно, в базе будет так:
Product
- Аспирин версии1
- Аспирин версии2
- Аспирин версии3

Properties
- Свойство 1, Аспирин версии1
- Свойство 2, Аспирин версии1
- Свойство 1, Аспирин версии3
- Свойство 2, Аспирин версии3
- Свойство 3, Аспирин версии3

Никаких деревьев там нет.
Без хибернейта делается просто join табличек с фильтром по версии.
Но опять же, зачем это? Вопрос был не архитектурный.
Вопрос чисто по хибернейту, как добавить в мапинг табличек доп условие по полю...

Petro123Ищущий Знаниябизнесу надо хранить версии... мне им сказать чтоб не хотели и выкинули базу за последние несколько лет с версиями?
смешно.
Если "хранить" - термин от бизнеса , то есть - OLAP\OLTP бэкапы и СиДиРОМы наконец))
Действительно смешно...
Кто хранит справочник товаров в бекапе на сидироме?
Хватит стебаться уже...
Если нечего сказать по делу, лучше не надо флудить и показывать какой вы "умный"...

ivanraПо-правильному, если в продукте раньше был ключ product_id, то теперь он должен стать составным (product_id, version), то же относится и к внешнему кючу в Properties. В хибернейте для этого создают специальный класс, в учебнике всё подробно расписано.
Судя по тому, что нарисовано, ключ так и остался product_id, то есть ваша таблица сейчас даже не во 2 нормальной форме. Хибернейт с такими таблицами работать не может, разве что с применением костылей.
Сделайте нормальный меппинг ключей и всё заработает

Спасибо.
Хоть кто-то пишет по делу...

PsolaoА так работать будет?
@ManyToOne
@JoinColumns({
@JoinColumn(name = "product_id", referencedColumnName="ID"),
@JoinColumn(name="version", referencedColumnName="version")
})

Неа, так не работает, уже попробовал. Говорит не может быть 2 поля "version".

Petro123да.
Привели бы схему БД с ID - давно бы всё было ясно.
Упрямый))

Для тех кто реально может помочь, все понятно.
А тем кто только и умеет что выпячивать собственную значимость, всегда что-то мешает... про танцора ведь в курсе? ;)

PsolaoВсе нормально - убери из основного класса поле version
Я чего-то не понимаю... Если я уберу это поле из основного класса, то как я буду узнавать его версию?

Psolao Гугл в помощь, вот нашел, надо делать композитный ключ

Спасибо, щас поковыряю.

Сергей АрсеньевИщущий Знания,

по по простому

Universal Product -> Versioned Product -> Properties

И в базе и в ORM сделать влом?

Походу это вам почитать топик в лом... повторю, база уже есть. Она работает и в ней есть данные. Просто так, сильно изменить структуру не получится. На нее надо натянуть хибер.
К сожалению, в жизни далеко не все складывается идеально, а жить как-то надо...

Petro123похоже он тут будет огрызаться и грубить ещё страниц надцать. К бабке не ходи))).
Тут архитектура вообще ни при чём, на которую он всё уповает и боится.

Да, к сожалению в рунете не получается не грубить.
Здесь мы видим классческий анекдот на вашем примере "Задаешь технический вопрос и тебе 2 страницы рассказывают почему ты редиска".
Хотя конечно это просто эмоции... гораздо проще таких болтунов игнорировать.

И да, от вас не было ни одного поста в тему вопроса, так с чего мне с вами любезничать?
Я сразу сказал, что не надо архитектурных решений и прочей фигни. Вопрос был чисто по хибернейту, по его мапингу, а не как версионность сделать. Есть простой технический вопрос. Но вам надо было показать что вы тут самый умный и умудренный опытом...
Конечно, когда нифига не знаешь и не можешь сказать по делу, начинают обычно умничать и делать из себя этакого умудренного опытом мудреца...

Только вот почему-то паре человек, с треда, ничего не помешало дать пару дельных советов абсолютно в тему. Ни отсутствие схемы БД, ни отсутсвие ID... А вы только и можете что выпендриваться своей крутизной. Ну что же, каждому свое, продолжайте чесать свое ЧСВ, засоряя форум флудом... ))

P.S. Да, приношу свои извинения. Одна мысль по теме все таки от вас была. Хранить версионность в бекапах на сидироме... снимаю шляпу за это гениальное изобретение)))

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

Нет, не через 2 таблицы. Просто 2 таблицы между собой связанные.

Petro123Psolao,
так?
productid version name2 2.0 Чел
propid id_product name values22 2 Рост 182

Да, именно так.

Ищущий ЗнанияДа, именно так.

Хотя нет, ошибся. Вот так будет ближе, хотя это конечно обрезанный вариант...
productid version name2 2.0 Чел
propid version id_product name values22 2.0 Рост 182

Petro123именно этот а-ля DDL вас сегодня просили целый день выдать.....путаясь в показаниях...Версия продукта у вас или версия свойства)).
Тяжёлый случай. Последний раз тут так просили помощи пол года назад.

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

Это реально очень тяжелый случай ))

Alex KuznetsovНе всегда.
Помимо версии "продукта" могут быть версии и у его "свойств".
Если, к примеру, за продукт принять документ, а за свойство принять какой-либо раздел или параграф, то как у документа могут быть разные версии, также и в рамках одной версии документа могут быть разные версии одного и того-же раздела.
Так что...

Именно об этом я и говорил. Версии есть не только у продукта, но и у свойств.
При чем понятие "версия", это не просто "положить в бекап на сидиром, вдруг понадобится".
С этими наборами постоянно идет работа...
Ну вот спроектировали так базу.
Пока софт на Java не переведем полностью, ничего нельзя менять.
Потом конечно подумаем, как отрефакторить все это безобразие.

Как вариант, представьте себе например анкету. У нее есть вопросы и есть ответы.
Список вопросов может меняться со временем + надо хранить историю ответов на каждый вопрос.
Вот и получается 2 сущности, и история есть и у вопросов и у ответов.
Хотя конечно все равно это абстракции и сути не меняют, все равно ведь не идеальную архитектуру требуется построить, а просто обернуть в хибернейт существующее...

Petro123...От понятия "История и Архив" до понятия "Текущий список вопросов" - дистанция огромного размера.
Хватит уже выеживаться и оперировать понятиями в которых вы, что называется, ни в зуб ногой...

Petro123Хибер не занимается архивами и историей Один-ко-Много.
Он просто делает Update And Delete. И правильно делает.
Если бы я знал хибер от и до, вопроса бы не было.
Но додуматься до этого вы не в состоянии))

Petro123Т.к. простейший CRUD упрощает Модель и ваши хотелки.
Обект-->Версия-->PropName-->Версия-->PropValues-->Версия
Ничего он мне не упростит в данной ситуации, ибо не я проектировал базу.
Пока я могу только использовать то, что есть.
Но вы не в состоянии это понять...