Например у меня есть много моделеи (до 30) каторые имеют поле name. Но так как ета програма дла несколких языков, то в модели есть такие поля:

А если мне надо добавить есчо адин язык ? Хочется держат тексты гдето оддельно. Но где ? В оддельной таблице думал, но тогда при стартупе придется грузить до 500.000 строк (для 3 языков). Да и как потом их использовать? В йсп я должен изпользовать чтото типо ${product.name} и оно должно вывести то name, для которого включена локаль. Как ви решали или решили би подобную проблему ?

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

Использю Spring 3.0 MVC, но както ненахожу, что могбы в нем использовать для речения своеи проблемы.

а зачем в базе хранить разные поля для каждого языка?

i18n со своими бандлами не решает проблему интернационализации хранимых объектов.. имхо.
Тут надо мутить какую-то связь. Так, если по-быстрому, то я бы сделал так: 




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



ну и сам метод 


Это то, что пришло в голову самое первое. А вообще, наверное, есть и другие варианты. Можно сделать и более гибкий и более абстрактный объект LanguageTranslation, в который можно было бы забрасывать совершенно разные объекты... думать надо

Неахота писать для 30 моделеи есчо 30 ModelNameLanguages (вет ето есчо 30 таблиц в базе данных).



Ето вы имели ввиду, чтобы был какойто сервис ? Да ето возможн, с ДАО получаеш лист обектов, подаеш в некий сервис и он записывает в поле модели name имя по включенной локали (например селетит из одной таблицы перевод для всех моделеи).

А может както возможо с hibernate interceptor, hibernate custom user type ?

Добавлено через 57 секунд


А как иначе ?

Вы меня не поняли, ну и ладно, теперь зато я понял.   

Мне честно говоря тяжело представить задачу, где нужно интернационализировать сущности... Обычно такая операция относится к заголовкам страниц, служебной информации, всякие там лицензионные соглашения, надписи на кнопках.. Но что бы имя, пусть того же, продукта...  А как пользователь будет вынужден создавать такой продукт? Вводить название на всех языках или только на том с какой локали он работает? А что если нет выбранной локали в БД? Тут предстоит учесть не мало мелочей. 

Нет, он сначала выберает, кокого типа продукт он создает.  Так вот ети типы и можно через админ редактировать. А усер просто видет каталог типов продуктов с именами в его локали.


Усер в интерфейсе сможет выберать толко те локали, которые запрограммированные в программе.

В таком случае, думаю, вам придется реализовывать логику управления  такими сущностями самостоятельно. 
Например создать класс для хранения локализованного значения имени и сделать связь коллекции таких имен с вашим продуктом.

Может быть имеет смысл использовать Map вместо List. В общем такая логика будет находиться под ответственностью вашего приложения, фреймворк, увы, не сможет взять её на себя.

Я тоже пришел к такоу решению, толка в продукте хранить название для самой употребляемой локали, например если сайт написант для росии, то хронить руское название (90% усерав будут использовать например), а отдельно названия на других языках (чтоб небыло много джоинов, тем самым улутшим перформанц).

Но мне неохота создавать для каждой сущности по отдельной таблице. Думаю создать чтото такого:



Только как потом примапить с Hibernate'ом в сущность product, все переводы где clazzName='Product' и objectId = ид продукта, чтобы било чтото такого:
 

Как описать такой маппинг с hibernate. Притом в Translations маппинга наверно небудет, так как его будет использовать много сущностей.

Вчера еще возникло похожее решение, но не успел отписаться. По-моему, оно будет более гибкое. 




В базе будет получаться что-то вроде такого


Таким образом можно переводить значения любых полей любого объекта. Относительно любого, конечно. 

Если очень хочется связей, чтобы дергать product.getTranslations(), то самым простым вариантом будет создать базовый класс, в котором прописать маппинг на TranslatableObject, и унаследовать от него все свои 30 хранимых объектов. Получится всего 2 дополнительных таблицы в базе. Код примерно такой



Но мне кажется, что лучше обойтись без мапинга. Проще будет, не будет проблемы lazy collections и всего такого. Просто заюзать TranslatableObject, Locale и какой-нибудь TranslatableObjectDao.




Это сообщение отредактировал(а) afon - 22.1.2010, 13:55

А в чем заключается проблема lazy collections ? Я как понимаю, если есть маппиг, то ненадо будет самому писать селекты минус один дао. А по перформацу, то какя раазница или я руками или хибернате выташит ети данные ?

Да и подумал, что так просто примапить мы несможет, так как фореигн кей будет неуникалным - в каждой таблице (из моих 30) может быть запись с ид=10. То если в TranslatableObject записать objectId=10, то етот TranslatableObject приампится для каздой сушности с ид=10. Я думаю надо будет дополнительно селектить и указывать simpleClassName. А после селектита создавать DTO обьект. Только получается что мне надо иметь сервис каторый будет трансформировать из хибернате обьекта в DTO и который поселектит переводы и запишет в DTO. 

Такчто сценарий такой:
1. Селектим хибернате обьекты из DAO.
2. С поможю сервиса конвертируем результат в DTO.

Как вам идея ? Какая критека ? 

Критека канткретная    читать то, что вы пишите, очень трудно. Так что уж потрудитесь...
А по сути: да дальше уже ваша собственная фантазия и конкретные прикладные проблемы все сделают. Мапить или нет, на какой id, сделать ли какой-то глобальный JoinTable верхнего уровня... зависит от  самого проекта. Дальше даже советовать трудно, не зная области... .

Это сообщение отредактировал(а) afon - 25.1.2010, 12:14