Comments 10
Как насчет «кеша» сущностей, чтобы дубли не вытаскивать?
Короче, я не совсем понимаю, зачем писать своё (кроме фана), когда для серьезных вещей ORM уже написаны.
Серьёзно? Это всё, что вас заинтересовало?
наложено требование на отсутствие проксей и единственный запрос
С lazyload/кэшом сущностей такое невозможно.
ORM уже написаны
В первой версии этого поста был еще большой кусок про то, зачем нам вообще нужен свой ORM и чем плох тот же Hibernate. Тем не менее, пост и так получился слишком большим, так что кусок был выпилен, т.к. это уже совсем отдельный вопрос. И к рассматриваемой проблеме отношения не имеет.
А так — согласен, если прокси критически неприемлемы, то остается вариант с постоянным указанием того, что же нам нужно.
Самое важное как раз постановка задачи, цель, так как этим определяется наличие или отсутствие каких-то фич, компромисы, которые можно сравнить с существующими продуктами и сделать вывод о необходимости написания какого-то своего решения.
Может быть вместо рефлекшена использовать кодогенерацию как в JOOQ? Может быть подсмотреть решения из EF(генерация запросов) или Dapper(маппинг и др) или использовать MyBatis (вдруг сойдет)? Есть еще миллион фич в разных ОРМ: кэши, компоненты, апи запросов, стратегии сохранения, оптимистик/пессимистик блокировки, поддержка хранимых процедур, поддерживаемые диалекты, сортировки, типы, обработка ошибок, легкий/тяжелый контекст/сессия, транзакции/распределенные транзакции, миграции и тп.
Lazy load — на серверах, как правило, скорее вредно, так как увеличивает количество запросов иногда неоправданно сильно. Если используется lazy load, я ищу причину такой необходимости. И опять же, как правило, это просто непродуманный дизайн.
Cache — вещь нужная, много где оправданная, но если бездумно ее включать, то неприятностей не оберешься. Ревалидация кеша это задача не хуже чем само создание солюшина. Перекладывать это бесконтрольно на ORM равносильно самоубийству.
Утверждение «не вытягивать дублирующиеся сущности» очень далеко от реальности. Они вытягиваются! Просто отсекаются при материализации. Если вы думаете что здесь получили существенный профит — вас обманули.
Это же суть всей Javы — разные взаимозаменяемые реализации для тех же самых стандартных наборов интерфейсов.
Ведь тогда Вы могли бы подключить Вашу ORM вместо того же Hibernate, провести какие-то сравнтельные тесты, могли бы обеспечить потенциально огоромное поле для внедрения в уже существующие проекты…
Спасибо! Вот неудобный вопрос вы задали. Можно сказать, что в val card = cardDAO.paritalGet<MsisdnAndBalance>(cardId), но это больше как шутка. На самом деле, довольно долго думал пихать ли в котлин, но по итогу решил, что раз такая реализация partialGet для использования из котлина так же хороша, как и из джавы, то пусть там тоже будет. Был бы хаб JVM, сунул бы только туда.
Упарываемся по максимуму: от ORM до анализа байткода