ссори за оффтоп, но подскажите плиз: есть Entity (например, User) и мне надо сделать @Immutable AdminUser extends User, у которого будет 1 дополнительное поле - @Formula(" length(name) ") можно ли в хибернейте(jpa) сделать такое наследование, не меняя базовый класс и не вводя dtype?

А у поля name нельзя длину взять?

у меня в базе 1000+ записей, мне нужно, чтобы в запросе присутствовал нужный мне where :-) иначе, я получаю лишь подмножество от этой 1000, в котором нет нужных мне записей

и у меня куча параметров, запрос приходится строить динамически -> Criteria api

вроде нашел решение: https://gist.githubusercontent.com/xmedeko/3898987/raw/490787d5282a7fbac9cb411cd1e9f35a50ed874f/NativeSQLOrder.java

Йода сказал бы: наследование в хибернейте не хочешь ты

Приветствую

Илья, привет

Йода сказал бы: наследование в хибернейте не хочешь ты

Хибернейт не хочешь ты. Совсем.

А что плохого в хибернейте? Отличная орм, явно лучше скала-аналогов, стоит признать

я бы даже сказал - пизже

Ого, хибернейт живой еще чтоли? Помнится, немало срача было о нем в году так 2009ом :)

Hibernate лучше?

Что за бред

Нравятся cross джоины?

Я юзал в скала не много orm но даже skinny orm которая работает поверх scalikejdbc лучше хибернейт

с одной стороны это кошмар СУБД (насмотрелся на аудите в свое время), с другой стороны подозреваю, что руками будут писать абсолютно также =/

lol, хибернейт прозрачнее и проще в разы чем любой orm на скале (без тысяч имплиситов, макросов и получасовой компиляции), документирован в разы лучше, комьюнити в разы больше

А сколько у вас конкретно опыт работа с Hibernate, может это я не прав

?

это круто что она задокументирована сверху до низу вот только от кривых решений внутри ORM это не спасает

Это нормально что нельзя сделать join если нет foreign key?

посмотрел на skinny, сидеть руками вытаскивать из ResultSet - это именно то, что я ожидаю от ORM :)

Нравятся cross джоины?

А какая разница хибер у тебя, слик или ещё что) если у тебя а базе структура херовая, то никуда не деться

поговорим о идеальных структурах БД специально под ORM?

в скале это не орм

это немного другое

ну мне привели в качестве примера его, я его и посмотрел

они как ORM ее позиционируют ну и там довольно много от ORM и ничего мепить руками там не надо

они как ORM ее позиционируют ну и там довольно много от ORM и ничего мепить руками там не надо

http://skinny-framework.org/documentation/orm.html

На самом деле проблема с joins решается очень просто, делаешь view которая по мере поступления сразу заполняет тебе таблицу для view

@Entity @Table @JoinColumn

это тоже самое

давай ты код сюда писать не будет. или хотя бы сделай моноспейсед

Одну денормализированную)

да, пардон, погорячился с кодом

На самом деле проблема с joins решается очень просто, делаешь view которая по мере поступления сразу заполняет тебе таблицу для view

я не спорю с этим можно и вьюху притащить но зачем если я могу сделать SELECT ... FROM ... JOIN и все ок будет

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

все сижу уже много лет на nosql

и мне норм =)

аннотации это не то же самое, я написал две аннотации - у меня хибернейт автоматически сделал за меня всё, мне НЕ НУЖНО прописывать как я и что хочу вытаскивать из гребанного ResultSet

клево

не надо тогда тебе скала

ну я лучше напишу что и как и не словлю потом проблемы с тем что 20 полей тащится из БД когда мне нужно 2 поля

а эти аннотации они интуитивно понятны?

они типо понятны, но залезть внутрь и посмотреть а что они делают

нереально

там такой треш из кода

а эти аннотации они интуитивно понятны?

ну если слова Entity, Table, JoinColumn тебе интуитивно понятны, то да

я не спорю с этим можно и вьюху притащить но зачем если я могу сделать SELECT ... FROM ... JOIN и все ок будет

Ну эт все до пары до времени, пока у тебя не 180 joins)

В это плане мне и нравится подход когда внутренний процессинг отделяют от view

Ну эт все до пары до времени, пока у тебя не 180 joins)

Hibernate с 180 джоинами не справится, будет у тебя 150 джониов 30 cross джоинов и еще че нить в придачу что будешь 2 недели разбирать нахер он ЭТО добавил в запрос

Hibernate с 180 джоинами не справится, будет у тебя 150 джониов 30 cross джоинов и еще че нить в придачу что будешь 2 недели разбирать нахер он ЭТО добавил в запрос

С чего вдруг он не справится?) эт СУБД бы справилась, хиберу пох думаю

аааа, а типо в слике и иже с ними можно прям вот так залезть и там СРАЗУ становится понятно интуитивно всё

я слик тоже не люблю я говорю о ORM которые приближены к SQL например ScalikeJDBC она много за тебя автоматизирует и в тоже время не ограничивает возможностями ORM

ну в смысле ScalikeJDBC не ORM но крутая тулза для работы с БД

так давай определимся, о чём мы говорим - об обертках над jdbc или о полноценных ORM, а то мы сравниваем не то не с тем

я говорю о том как работать с БД и если мы говорим о ORM то я хочу доказать что такие как Hibernate не нужны и их можно заменить более гибкими и легкими либами

С чего вдруг он не справится?) эт СУБД бы справилась, хиберу пох думаю

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

Да, согласен, одна таблица круче

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

я говорю о том как работать с БД и если мы говорим о ORM то я хочу доказать что такие как Hibernate не нужны и их можно заменить более гибкими и легкими либами

окей, смотри - мы говорим об ORM, ты говоришь, что хибер не нужен. Приведи пожалуйста пример скаловской ORM, которая "круче" хибернейта и почему

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

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

Может, чем б не мочь то

это работает на маленьких проектах или с простой бизнес-логикой

а еще полноценные орм для людей без фантазии! во!

это работает на маленьких проектах или с простой бизнес-логикой

Эт и на крупняках работает

object oriented impedance mismatch

как это по-русски?

Рибята для хибернейта есть другой чат —> там была где-то ссылка на это *

круче по каким критериям? По функционалу Hibernate впереди всех, но по простоте она в жопе, Skinny ORM реализует часть функционала Hibernate это меппинг полей, связи(OneToOne, ManyToOne, OneToMany, ManyToMany) в остальном берем Scala и все от ORM больше ничего не надо что плохо в Hibernate: 1. Генерит сложные запросы, привет CROSS JOIN в неочевидных местах 2. Не умеет в JOIN без Foreign Key, а если я не могу юзать NoSQL бд а мне нужно атрибутное хранение? 3. Не умеет в иерархии, Closure Table, Nested Set и т.д. пишем руками на SQL 4. Сессии и куча проблем с ними, паттерны которые просто мусор в голове разработчика(SessionInView) 5. Транзакция привязывается к потоку, привет асинхронность(точнее пока) 6. Неочивидная политика Flush, целый раздел когда флашить сущности, нахрен мне в вебе такое например? 7. Аннотации которые не работают или работают плохо, например @Any вроде норм аннотация но JOIN по ней сделать нельзя еще куча вещей которые я забыл

для лютых выебонов типа "наша ява может лямбды скала не нужна" вы выбрали неверный чатик. =)

Что все так не любят squeryl, он тож орм простой

причем с новым разработчиком

еще где то был SORM

Нах вообще орм, я пишу всегда SQL руками

в скала почти любая ORM хорошая

ну что я трогал кроме Slick

для меня слишком сложно

ну что я трогал кроме Slick

Слик просто гавно

squeryl очень мощная

по моим ощущениям

ну это больше просто ощущения чем реальный опыт

ну я пользовался им прилично, и не было каких-то прям супер косяков

squeryl же в рантайме тормозной

воу воу господин 100к запросов в секунду на проде?

нет, это голословное заявление, слышал от знакомого, пруфов не будет)

ясненько

)

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

Олсо в гибере есть теперь критерияапи и фетчграфы и они даже работают. :-)

Правда в итоге получается 80%аннотаций в проекте

все чтобы не делать JOIN в запросе

Все равно джойны говно и медлено

7080ннннопж0