Всем доброго времени суток!

Изучая EntityBean задался таким вопросом:

Пусть существует некий объект Entity-бина с неким набором полей.
Пусть выбран вариант с Container-Persistence Management.
Если мне понадобиться ввести новое поле и я сделаю это в коде, как эти изменения отобразятся на БД? Обновит ли контейнер структуру БД автоматом или что-то непоправимое случится?


Всем заранее спасибо!

ЗЫ: гуглил - ненашел :(

Это сообщение отредактировал(а) kaa - 21.12.2008, 16:38

Проверил - ессно валится с ексепшеном.


Может быть опытные товарищи подскажут, как поступают в случаях, когда структура бина (а значит и таблицы) требует обновления?

Привет. Вообще что-то ты не стандартное загадал.
Суть отражения базы в объекты Java как раз-то и сводится к постоянству(от слова persistance).
Изменения схемы базы можно делать во время деплоя, когда подымается persistanceContext.

А вот в рантайме естественно этого не сделаешь.
А ну-ка вызови из Java кода

А если потом еще захочешь удалять какое-нибудь поле?

Да и к стати поясни, как ты в рантайме добавляешь филды объектам? Что-то новенькое(для меня).

В случае, если какая-то не стандартная структура возможна у таблицы в зависимости от контекста, например.
То есть вариант хранить новые поля в одной колонке в Lob и структуре XML.
Oracle вообще позволяет делать своеобразные запросы на xml-колонки

MisterCleric, 
Не, я не в рантайме 

Я делаю undeploy, добавляю поле в класс бина, потом деплою. При деплое он ессно лезет создавать таблицу заново...

В общем, как я понял, добавка поля в класс выливается в целый процесс, не, даже ПРОЦЕСС - обновление приложения  С портирование данных из старой базы в новую 

Вообще-то можно схему при деплое и обновлять, 
Но я вот нашел некоторое "НО"

http://forum.hibernate.org/viewtopic.php?t=940659

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

Я вообще в своих в своей схеме создаю кучу вспомогательных таблиц, которые нужны чисто для статистики или для логики в хранимых процедурах (например, временные таблицы).
Соответственно, многие из таких объектов не находят себе места в логике на Java, как, к стати, и некоторые колонки в таблицах не отражены в сущностях
Так что думай

MisterCleric, 

Тоесть правильнее использовать Entity с персистентностью управляемую бином а не контейнером, я правильно понимаю?

Стоп. Может мы вообще о разных вещах говорим?
Я говорю о JPA+EJB3+Hibernate
А ты, наверное, о EJB2 EntityBean?

решение простое:
добавил поле в бин, будь добр прогрузи соотв скрипт на изменение таблицы. Так как мало того что поле может быть notnull оно так же может быть ключем или иметь другие ограничения.
Изменение структуры таблиц при изменнии бинов считаю пагубной практикой - может вылится в потерю данных.

MisterCleric, 

Я про EJB3.0 на Glassfish, там по умолчанию не Hibrnate используется 


necromancer, 
А как же апдейт программы?
Но, в общем, мысль понял.



Это сообщение отредактировал(а) kaa - 24.12.2008, 13:54

апдейт программы можно делать прогружая сприпты через SQL, не полагаясь только на контейнер и делать это желательно перед стартом контейнера.

Собственно так всегда и делалось.
И я не понимаю, почему люди подымают подобные вопросы постоянно. Как будто боятся что-то в базе менять или из-за не знания SQL...

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

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

MisterCleric, 

Ну, я поднимаю потомучто незнаю многих вещей и только начинаю в этом копаться.
С SQL-ем я вроде дружен. 
А насчет адаптированного приложения под базу - так это ж приязывает её к одной базе, разве нет?

скорее это привязывает приложение к структуре данных.
Привязка к базе относится к таким малоприятным вещам, как:
1. хранение blob или других спец данных
2. хранимые процедуры/триггеры/функции
3. работа с XML посредством СУБД
4. использование драйверов =)
5. хитрости синтаксиса SQL запросов (например limit в MySQL)
6. автоикременты, последовательности

С большинсвом этих проблем можно справится на этапе проектирования приложения. Остается вопрос а надо ли?
Ведь если ваше пирложение является достаточно сложным и заранее планировалось для испоьлзованиян а одной СУБД, то переход на другую СУБД очень мало вероятен =)
Если же у вас коробочный продукт с заявленной поддержкой кучи СУБД, то для таких целей подойдет hibernate и наименьшее кол-во чистого SQL и "фич" баз данных. Например генерировать уникальные ключи придется самому или через спец класс, который будет "знать" какая у тебя СУБД.

necromancer, 

Ага... Понятненько!


Всем большое спасибо за ответы!