JPA: замапить поле типа Image

@Gepar · Регистрация: 01.07.2009

Студворк — интернет-сервис помощи студентам

Есть ли возможность как-то пометить поле сущности аннотацией чтобы оставить его как Image, а не как массив байт ?
Ну тоесть сейчас есть:

Java
1
2
3
4
5
6
7
8
9
@Entity
@Table(name = "PERSON")
@XmlRootElement
public class Person {
    @Id
    private Integer id;
    private String firstName;
    private String lastName;
    private int age;

А я хочу что-то вроде этого:

Java
1
2
3
4
5
6
7
8
9
10
11
@Entity
@Table(name = "PERSON")
@XmlRootElement
public class Person {
    @Id
    private Integer id;
    private String firstName;
    private String lastName;
    private int age;
    @Lob
    private Image photo;

private byte[] photo меня не устраивает.
Собственно почему хочу именно так: Image автоматически при конвертации в xml кодируеться как base64 и в итоге от меня не надо никаких велосипедов и телодвижений при использовании объекта на стороне клиента, если же я впишу byte то всё уже не будет так мультиплатформенно и красиво, а ведь мне возможно придёться этот объект из xml получать и не только в java и соответственно могут возникнуть проблемы потом как это назад в картинку вернуть. Конечно есть вариант ещё хранить в базе сразу в base64 значение и в итоге сделать обычное поле String, но согласитесь поле String photo64; как-то дико выглядит, да и неудобно это будет.

Добавлено через 8 минут
Более вдумчивое чтение ошибки натолкнуло на мысль
Exception Description: The type [class java.awt.Image] for the attribute [photo] on the entity class [class entity.Person] is not a valid type for a lob mapping. For a lob of type BLOB, the attribute must be defined as a java.sql.Blob, byte[], Byte[] or a Serializable type. For a lob of type CLOB, the attribute must be defined as a java.sql.Clob, char[], Character[] or String type.. Please see server.log for more details.
Вот только чтобы мне такого взять Serializable для изображений в java ...

@KEKCoGEN · 23.11.2014, 20:08

Сообщение от Gepar

использовании объекта на стороне клиента

Это плохая практика - использовать DAO классы на стороне клиента. Для этого есть DTO классы и есть логика приведения. Если вы будите предерживаться это конвенции, проблемы не возникнет.

@Gepar · 23.11.2014, 20:58 **[ТС]**

KEKCoGEN, я добавлю DTO как только в нём возникнет необходимость, в моём примере список полей для клиента тот же что получает сервер и пока что смысла в ещё одном объекте-прослойке нет (логично что клиент использует облегчённый объект у которого нет аннотаций и прочего, но за счёт xml всё декодируеться как надо). Пока что я всё же хотел бы заставить мапиться мой blob на какой-то аналог Image который потом можно загнать в xml как base64 ...

Добавлено через 23 минуты
А вообще я согласен что в реальной жизни у меня там будет DTO и всё будет красиво, наверное, но ... как тогда принято хранить изображения в базе чтобы удобно мапить через JPA? В виде base64 и делать поле String photo64 или как? Ато у меня нет опыта работы в написании серверной части так что я не видел "как надо", я сейчас работаю как субд'шник, а не программист java.
Вообще я так понимаю у тебя опыт есть и я был бы весьма признателе если бы ты слил мне какой-то из своих проектов где всё канонично, в идеале если бы это был какой-то проект RESTful сервиса (если у тебя такой есть). Ато извечная проблема: в книгах с пометкой "для профессионалов" есть hello world'ы, а также пример сервиса раздающего информацию о книгах или о людях (где два или и вовсе один объект замаплены и раздаються сервисом), чего-то полноценного там нет

@turbanoff · 23.11.2014, 22:04

а чем вас байтовый массив не устраивает?

@KEKCoGEN · 23.11.2014, 23:58

насчет dto это не только удобство но и безопасность. передавать клиенту поля id базы данных небезопасно тк это значение легко предсказуемо и следовательно дает возможность через рест запросы получить информацию об объектах соседях. Представьте например что вы храните номера банковских счетов и по какому то запросу представляете информаицю о счете. В передаваемом объекте будет фигурировать id и соответственно можно будет легко получить соседние счета просто прибавив или отняв единицу. Пример конечно утрированный однако суть думаю ясна.

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

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

Добавлено через 47 секунд
извиняюсь за опечатки если есть. Пишу с таблета

@Gepar · 24.11.2014, 01:28 **[ТС]**

Сообщение от KEKCoGEN

насчет dto это не только удобство но и безопасность. передавать клиенту поля id базы данных небезопасно тк это значение легко предсказуемо

Ну в таких случаях поможет разграничение доступа (нельзя пользователю смотреть id xxxxxx - отдать пустую страницу или допустим генерация id'шников от балды с разбросом, у гугла и оракла вон даже библиотеки для этого есть, ну да сейчас не об этом.
Как же я тогда пользователю буду отдавать Person без id, а если он скажет обнови мне Васю Пупкина, он фамилию сменил на Васин то как я буду знать что за Пупкин у меня там в базе должен обновиться, может у меня их уже 10ок так что вопрос с тем как передать пользователю объект без id для меня не очевиден, а если пользователь скажет "У васи id = 3" то ок. Ну можно ещё ref ссылку всунуть (я видел пример в одной из книг), но то что у объекта есть поле String ref = "api/Person/23" ничем не лучше String id = "23", вообще можно даже private String id сделать, чтобы пользователя меньше смущало это всё, но я не вижу выхода без id.
Да и если смотреть дальше: у Личности есть адресс (ещё один объект), телефон (ещё один объект) и электронная почта (допустим это тоже объект). Я планировал отдавать клиенту следующий объект при запросе персоны по id:
id персоны
фио
дата рождения
id адреса
id телефона (это не имеет смысл, но будем считать что телефонные записи содержат ... ну пускай домашний, мобильный, пейджер, запасной номер и т.д, тоесть нельзя оставить просто полем)
id почты

Дальше если нужен телефон персоны то можно имея объект персоны по idшнику запросить у сервиса телефон и т.д. В общем я и сам вижу что я продолжаю смотреть в разрезе хранения объектов в бд, видимо сказываеться то чем я занимаюсь последние пол года на работе, но я не вижу решения лучше. Ведь я не могу при запросе персоны по id отдавать ему xml'ину с данными подтянутыми по 10 таблицам через fk, это ведь неправильно будет когда кто-то ищет персону по фамилии "Пупкин", а я ему вместо того чтобы отдать "Вася пупкин, код телефона 1" отдам Васю Пупкина весом в 10кб xml'я со всеми его адресами и половыми связями ... Как же мне тогда поступить ?

Сообщение от KEKCoGEN

Насчет проектов. большие энтерпрайз проекты которые я пишу на работе прислать я не могу по понятным причинам

Так не надо большое, копирни прямо в ide по классу-два, если можно, с каждого уровня (пускай остаються неразрешённые ссылки на всё остальное и в итоге оно не компилиться даже, это не помешает) чтобы можно было посмотреть как красиво мапить и как строить архитектуру от объекта в базе до ответа клиенту от веб сервиса. Если получиться то скинь в личку пожалуйста, это чтобы не светить уж чтобы тебе точно не перепало

Сообщение от turbanoff

а чем вас байтовый массив не устраивает?

Нууу ... наверное потому что там фото, а не байтовый массив

Хотя в принципе наверное хранение в base64 будет не столь плохим вариантом как мне казалось в самом начале.

Добавлено через 7 минут
Ну или просто поделитесь кто-то ссылкой пожалуйста на взрослый проект restful сервиса где есть также работа с бд, hello world'ов в сети пруд пруди, в литературе, к сожалению, тоже. Ну или может вы встречали какую-то взрослую книгу где не просто обо всём на свете понемногу, а есть уклон именно в разработку такого рода сервиса с реализацией (без реализации 500 страниц суждений о том как должен вести себя restful сервис и как он прекрасен я уже тоже находил и листал). Отмечу что я уже пытался найти что-то путнее на гитхабе и битбакете, но хелло ворлды с одним классом, одним сервисом и одним методом GET преследовали меня и там, может я не столь удачно подобрал ключевые слова, но реально у меня в итоге нет ни одного полноценного примера как делают те кто с опытом.

@KEKCoGEN · 24.11.2014, 07:38

Ну в таких случаях поможет разграничение доступа

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

Как же я тогда пользователю буду отдавать Person без id

для этого есть uuid. Строка длинной 32 символа специально сгенерированная при создании сущности. Она передается клиенту.

Да и если смотреть дальше: у Личности есть адресс (ещё один объект), телефон (ещё один объект) и электронная почта (допустим это тоже объект). Я планировал отдавать клиенту следующий объект при запросе персоны по id:
id персоны
фио
дата рождения
id адреса
id телефона (это не имеет смысл, но будем считать что телефонные записи содержат ... ну пускай домашний, мобильный, пейджер, запасной номер и т.д, тоесть нельзя оставить просто полем)

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

@Gepar · 24.11.2014, 12:44 **[ТС]**

Сообщение от KEKCoGEN

Строка длинной 32 символа специально сгенерированная при создании сущности. Она передается клиенту.

С этим понятно, для моего проекта это лишнее, но я запомню.

Сообщение от KEKCoGEN

Например на экране информации о юзере вы хотите показать фио, номер телефона и адрес почты. Таким образом при вашей реализации на каждый запрос страницы вы 3 раза выпустите рест запрос, пойдете в аппликацию и что еще хуже, пойдете в БД.

Тут ведь есть две стооны, я не зря спросил как лучше:
Вариант 1) Клиент запросил персону из сервиса по id, вероятно он будет отображать её в gui полностью с городом, телефоном и т.д - отдаём ему Персону и к ней в придачу объект Адрес, Телефон, Почта, МестоРаботы ... в общем 10кб xml'я.
Вариант 2) Пользователь ищет всех кто живёт в городе Кукуевск, он ожидает получить список Персон (в любой системе ведь возникнет ситуация когда надо искать по каким-то параметрам и в ответ надо будет отправить список результатов) ну или скажем он хочет найти всех у кого день рождения в этом месяце, не столь важно: важно что он ищет список людей и результатов может быть много, допустим 100. Учитывая эти особенности несложно догадаться что клиенту в таких случаях врятли нужны полные данные, ему хватит и фио чтобы списком вывести в gui те персоны что подошли по параметрам.

Как же я тогда должен поступить когда у меня есть два варианта использования: когда клиент запросил персону и ему надо все данные и когда клиенр ищет что-то и результатом будет список данных о персонах, где клиенту пофиг с какого они города и какой у них адрес, вероятн он выберет одну персону из списка которая и была нужна и уже по ней запросит полные данные.

У меня пока возник только простейший вариант: отдавать клиенту Персону включащую все перечисленные поля-объекты, но сделать их подтягивание опциональным (в виде доп. параметров запроса, например api/person/search=Kukuevsk&Address&Phone&WorkPlace) только если пользователь запросил их в виде параметров иначе вместо них возвращать null, но у этого подхода ведь тоже есть минуса - клиенту постоянно надо проверять всё на null'ы и переполучать данные по персоне заново если надо дотянуть какое-то поле

В общем я поэтому и прошу какой-то более удачный пример, ато мой набросок с персонами (это мой тестовый проект где я стараюсь пройтись по всем проблемам что будут у меня в реальном проекте: список результатов, поля с изображениями, поля с датами, подтягивание полей связанныщ с сущностью из других талиц) выглядит стрёмно, мне бы что-то из реального мира где всё сделано по канону

@KEKCoGEN · 25.11.2014, 17:46

Сообщение от Gepar

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

Отображать 100 результатов - плохая практика. Нужно отображать постранично например по 10. Никто никогда в жизни не смотрит 100 результатов.

Думаю тема стала оффтопом и лучше свернуть обсуждение.

@Gepar · 25.11.2014, 20:00 **[ТС]**

Не по теме:

Сообщение от KEKCoGEN

Думаю тема стала оффтопом и лучше свернуть обсуждение.

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

Новые блоги и статьи Все статьи Все блоги /
Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Нашел на реддите интересную статью под названием «Кто-нибудь знает, где получить бесплатный компьютер или. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro
Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .

@Gepar 1186 / 543 / 78 Регистрация: 01.07.2009 Сообщений: 3,517
	23.11.2014, 20:58 [ТС]
	KEKCoGEN, я добавлю DTO как только в нём возникнет необходимость, в моём примере список полей для клиента тот же что получает сервер и пока что смысла в ещё одном объекте-прослойке нет (логично что клиент использует облегчённый объект у которого нет аннотаций и прочего, но за счёт xml всё декодируеться как надо). Пока что я всё же хотел бы заставить мапиться мой blob на какой-то аналог Image который потом можно загнать в xml как base64 ... Добавлено через 23 минуты А вообще я согласен что в реальной жизни у меня там будет DTO и всё будет красиво, наверное, но ... как тогда принято хранить изображения в базе чтобы удобно мапить через JPA? В виде base64 и делать поле String photo64 или как? Ато у меня нет опыта работы в написании серверной части так что я не видел "как надо", я сейчас работаю как субд'шник, а не программист java. Вообще я так понимаю у тебя опыт есть и я был бы весьма признателе если бы ты слил мне какой-то из своих проектов где всё канонично, в идеале если бы это был какой-то проект RESTful сервиса (если у тебя такой есть). Ато извечная проблема: в книгах с пометкой "для профессионалов" есть hello world'ы, а также пример сервиса раздающего информацию о книгах или о людях (где два или и вовсе один объект замаплены и раздаються сервисом), чего-то полноценного там нет 0

@turbanoff 4094 / 3828 / 745 Регистрация: 18.05.2010 Сообщений: 9,331 Записей в блоге: 12
	23.11.2014, 22:04
	а чем вас байтовый массив не устраивает? 1

@KEKCoGEN 2399 / 2224 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	23.11.2014, 23:58
	насчет dto это не только удобство но и безопасность. передавать клиенту поля id базы данных небезопасно тк это значение легко предсказуемо и следовательно дает возможность через рест запросы получить информацию об объектах соседях. Представьте например что вы храните номера банковских счетов и по какому то запросу представляете информаицю о счете. В передаваемом объекте будет фигурировать id и соответственно можно будет легко получить соседние счета просто прибавив или отняв единицу. Пример конечно утрированный однако суть думаю ясна. насчет того как хранить в бд изображения. в идеале никак. Изображения должны лежать на диске и выдавать их должна не аппликация а apache например. Тем самым весь статик контент не проходит через томкат и тем более медленную бд и не нагружает систему. Если же все таки картинки лежат в бд, то имхо большой разницы как хранить нет. Как удобно... Насчет проектов. большие энтерпрайз проекты которые я пишу на работе прислать я не могу по понятным причинам, а последний раз когда я писал веб аппликацию один - был в универе и исходников уже давно нет да и это вряд ли могло бы служить каким либо примером. Добавлено через 47 секунд извиняюсь за опечатки если есть. Пишу с таблета 1