ch
Size: a a a
2020 April 29
h
Два поля тогда походу единственный выход, иначе нужен общий предок
Ну два поля и будут, просто инкапсулированы в контейнер Билет, где проверяется, что только один из двух вариантов билетов может существовать.
ch
humanoid
Ну два поля и будут, просто инкапсулированы в контейнер Билет, где проверяется, что только один из двух вариантов билетов может существовать.
Это в 90% случаев костыль
h
Из @Embeddable можно ссылаться на энтити?
h
Это в 90% случаев костыль
Костыль вплане прийдется писать, тк в jpa такого варианта нет?
ch
humanoid
Костыль вплане прийдется писать, тк в jpa такого варианта нет?
Костыль в плане вы забили на ООП без веской на то причины
h
Костыль в плане вы забили на ООП без веской на то причины
Поясните позицию, а то я только услышал, что это костыль, что я забил на “ооп”, а почему не услышал
h
По сути без orm, я бы хранил в таблице два поля референса на разные таблицы. А маппил бы их в отдельный как раз объект Ticket.
h
Я как раз обязанность-инвариант, что билет может быть только либо забронированным, либо отмененным налагаю на объект билет. И выражаю это через типы
D𝔇
Можно попробовать сделать общего предка - entity со стратегией наследования таблица на класс.
Других мыслей пока нет.
А на уровне бд какие-то проверки есть? fk?
Других мыслей пока нет.
А на уровне бд какие-то проверки есть? fk?
h
Можно попробовать сделать общего предка - entity со стратегией наследования таблица на класс.
Других мыслей пока нет.
А на уровне бд какие-то проверки есть? fk?
Других мыслей пока нет.
А на уровне бд какие-то проверки есть? fk?
Я сейчас понял, наверное это не java-way проверять типо if(ticket instanceof BookedTicket){ …
Паттерн матчинга нет, sealed нет.
Видимо java-way - просто хранить два поля на разные таблицы, а в энтити проверять на null
Паттерн матчинга нет, sealed нет.
Видимо java-way - просто хранить два поля на разные таблицы, а в энтити проверять на null
h
Надо делать проще) Разве не для этого я jpa и взял)
D𝔇
Чем больше проверок целостности данных производится на уровне СУБД, тем лучше. Без разницы на чем приложение
h
Чем больше проверок целостности данных производится на уровне СУБД, тем лучше. Без разницы на чем приложение
Ну я больше приверженец строгости на уровне приложения, а не бд. В бд только констрейнты для оптимизаций, по сути индексы.
Логику в бд сложнее поддерживать
Логику в бд сложнее поддерживать
BP
Чем больше проверок целостности данных производится на уровне СУБД, тем лучше. Без разницы на чем приложение
*на РСУБД 🌚
D𝔇
Ну здесь речь о рсубд, насколько я понимаю :)
D𝔇
humanoid
Ну я больше приверженец строгости на уровне приложения, а не бд. В бд только констрейнты для оптимизаций, по сути индексы.
Логику в бд сложнее поддерживать
Логику в бд сложнее поддерживать
Не логику, только констрейнты.
А что вы будете делать, когда админ Вася случайно поправит данные так, что будут привязаны одновременно оба типа билетов?
А что вы будете делать, когда админ Вася случайно поправит данные так, что будут привязаны одновременно оба типа билетов?
h
Не логику, только констрейнты.
А что вы будете делать, когда админ Вася случайно поправит данные так, что будут привязаны одновременно оба типа билетов?
А что вы будете делать, когда админ Вася случайно поправит данные так, что будут привязаны одновременно оба типа билетов?
Ну у нас нет такого админа Васи, у нас этип схемой программисты занимаются, а так конечно же руки ему оторвать)