Comments 9
Рекомендации
Не юзать Hibernate в проде.
Просто не юзать в проде никаких general purpose средств для скаффолдинга чего бы то ни было. Вот так вот — совсем не юзать этот класс инструментов, включая любые «общие» ORM, от слова вообще.
Для быстрого прототипирования — не возбраняется. Они идеально для этого подходят, потому что пытаются охватывать все кейсы на свете, но при этом не заточены ни под один реальный кейс. Но для прода пишите минимальные имплементации, специализированные под ваши задачи, сами.
Вы готовы обосновать заказчику (или боссу вашей компании), что стоимость разработки будет в пять раз больше из-за рекомендации номер ноль на Хабре? Как вы обоснуете?
плюс найти разработчиков на такой проект будет сложнее
в пять раз больше - цифра вытащена из жопы. Что такого принципиально сложного и долгого в написании sql запросов и маппинге?
Вот этот инцидент на проде - сколько на него потрачено времени, денег? Сколько ещё таких инцидентов было/будет?
сколько? я думаю не много. и до и после него, тем более что сейчас все легко обмазывается метриками и они часто уже идут из коробки. сколько будет с рукописными кверями? а рефакторить как? ладно вытянуть данные не трудно, а обновить? особенно когда вы уже привыкли работать с графом объектов. не просто так есть параметр для any со степенью двойки, значит автор не первый кто с такой проблемой встретился. куда проще и безопасней разобраться с orm чем писать свою, с кучей багов и повторением чужих ошибок в процессе обучения, а к этому по итогу все и придет.
Это с какого перепугу в пять раз?
Минимальный объектный маппер для SQL пишется за два рабочих дня. Потому что в рамках любого отдельно взятого проекта используется от силы 10% от всей функциональности, которую с собой тащит комбайн типа Хибернейта. Остальное нафиг не нужно, но проблемы, типа описанной в посте, создаёт.
Я как бы не один год провёл в кровавом ынтерпрайзе, и писал их много раз, так что знаю, что советую =)
Раньше я сам оч любил Хибер)) Но чем глубже его изучаешь, чем больше сталкиваешься со всякими нюансами в проде, тем яснее, что это довольно сложный инструмент. Ошибиться или допустить незаметный для разработки кейс, который вылезет в рантайме оч легко
Поэтому у нас на платформенном уровне сейчас есть рекомендация по возможности уходить в сторону Spring Data JDBC или jooq, где меньше магии и больше контроля over sql)
Как IN (:ids) раздувал Hibernate Query Plan Cache до 100+ МБ и почему ANY(:ids) спас прод