LINUX.ORG.RU

java orm которые тоньше самого тонкого тролля

 ,


0

2

в идеале нужно чтобы он позволял

- маппить результат произвольного sql запроса на объект

- принимать объект строки запроса в Consumer

// вместо
List<T> selectAll();

//надо
void selectAll(Consumer<T> consumer);

- некоторый примитивный criteria api (или просто позволять юзать кусок sql из where не указывая весь запрос с десятком полей)

- маппить объект на аргументы произвольного запроса

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

- ничего не делать с foreign key и ключами - т.е. позволять с ними работать в ручную

MyBatis\ibatis не предлагать - там sql в xml и воще кошмар.

Deleted

Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Crocodille

гуголь уйди, ты хоть пост читал, или только кейворды выбрал?

Deleted
()
Ответ на: комментарий от holuiitipun

Вот, мне интересно есть ли аналоги, эта пока что только consumer не поддерживает

Deleted
()

Вроде из этого всё кроме генерации запросов умеет spring-jdbc.

migesok
()
Ответ на: комментарий от Deleted

mybatis generator и потом сделать как например тут.
генерить он на лету он не умеет, но он достаточно простой сам по себе и позволяет мапить произвольные квери
конечно если он вам не нравиться, тут я ничего не могу поделать

rusich
()

xml и воще кошмар.

Фанатики должны страдать.

anonymous
()
Ответ на: комментарий от rusich

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

Deleted
()

MyBatis\ibatis не предлагать - там sql в xml и воще кошмар.

Я сейчас малость не по сабжу, но всё-таки советую на Apache Cayenne посмотреть. На самом низком уровне оно работает с Map'ами, а sql templates у него описаны на velocity. Ну и да, запросы оно само не построит. Удваиваю вопрос ТС.

bytecode ★★
()
Последнее исправление: bytecode (всего исправлений: 1)
Ответ на: комментарий от Debasher

Предлагаешь ручками запросы писать и мапить на структуры данных языка? Или у тебя есть альтернатива?

loz ★★★★★
()

Посмотри jooq, может понравится.

Legioner ★★★★★
()
Ответ на: комментарий от loz

Предлагаешь ручками запросы писать и мапить на структуры данных языка?

Да. Ну, естественно не смешивать SQL с кодом, выносить его в отдельный(е) файл(ы).

Debasher ★★★★★
()
Ответ на: комментарий от Debasher

Ну очевидные преимущества orm в том, что не нужно быть профессионалом в sql, специалистом по базам данных, может оптимизировать какие-то неочевидные вещи, ну и в конце концов дает тебе объектную абстракцию над примитивными данными.

А какие аргументы за чистый sql?

loz ★★★★★
()
Ответ на: комментарий от loz

единственная задача orm избавить программиста от рутинной возни с resultSet.getObject(i) (ой а какже null?) при чтении и записи

Deleted
()
Ответ на: комментарий от loz

Ну очевидные преимущества orm в том, что не нужно быть профессионалом в sql

Нет, ORM поможет разве что на элементарных запросах. Любой сложный запрос как правило сначала тестируется в 'repl'-е БД, и потом наступает геморой с его переводом в ORM-вид. Иначе просто никак.

А какие аргументы за чистый sql?

Например разделение логики - в фирме может быть один специалист по БД, который на все проекты штампует запросики.

Ну и вообще - в данном случее меньше абстракций - меньше ошибок

Debasher ★★★★★
()
Последнее исправление: Debasher (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

loz ★★★★★
()
Ответ на: комментарий от Debasher

Любой сложный запрос как правило сначала тестируется в 'repl'-е БД, и потом наступает геморой с его переводом в ORM-вид. Иначе просто никак.

Возможно, особо сложные запросы я не делал ни в том, ни в другом виде.

Например разделение логики - в фирме может быть один специалист по БД, который на все проекты штампует запросики.

«Фирмы» обычно предпочитают нанимать универсальных людей, которые могут заменять друг друга. Не все, конечно, но обычно так.

меньше абстракций - меньше ошибок

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

loz ★★★★★
()
Ответ на: комментарий от loz

позволяет писать независимо от диалекта и возможностей конкретной базы.

Лорчую этого оратора. SQL это такая фигня, стандарт на которую как-бы с одной стороны есть, а с другой стороны никто его не придерживается, и делает все, как хочет, что делает миграцию проекта с одной СУБД на другую и без того болезненной.

cherry-pick
()
Ответ на: комментарий от loz

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

Deleted
()
Ответ на: комментарий от loz

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

чем jpql не дает допустить ошибок?

Deleted
()

Я ничего не понял.

Самый примитивный _типа_ ORM - это «Spring Framework JDBC».

(искать org.springframework.jdbc.core.JdbcTemplate)

Курите доку и разбирайтесь с примерами.

Bioreactor ★★★★★
()
Ответ на: комментарий от Deleted

А зачем Вы спрашивали, если сами не поняли, что спросили?

Без знаний «Спринга» Вам светит только должность «веб-мастера» в мухосранске.

С последующим разжалованием в эникейщики.

Читать сюда

«This is the central class in the JDBC core package. It simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results. This class executes SQL queries or updates, initiating iteration over ResultSets and catching JDBC exceptions and translating them to the generic, more informative exception hierarchy defined in the org.springframework.dao package.»

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

А зачем Вы спрашивали, если сами не поняли, что спросили?

Ты уже забыл? что сам не понял и приписываешь это мне? 8)

Без знаний «Спринга» Вам светит только должность «веб-мастера» в мухосранске.

Спринг говно, авторитетно заявляю.

Deleted
()
Ответ на: комментарий от Deleted

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

Как-то не логично, таблички строятся исходя из того что надо будет запрашивать.

loz ★★★★★
()
Ответ на: комментарий от loz

«Фирмы» обычно предпочитают нанимать универсальных людей, которые могут заменять друг друга.

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

синтаксических

допустим

логических

ой не факт, скорее своих добавит

возможностей конкретной базы

мне кажется в мало-мальски сложной логике юзаются субд-специфичные штуки которые всю 'универсальность' на нёт сводят

Debasher ★★★★★
()
Ответ на: комментарий от loz

Не знаю что это, но

зачем тогда отвечать то?

Deleted
()
Ответ на: комментарий от loz

Как-то не логично, таблички строятся

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

Deleted
()
Ответ на: комментарий от loz

в общем случае у тебя орм сформирует запрос так, чтобы он был валидный

«В общем» случае это до первого факапа.

У меня hibernate генерировал невалидный SQL, что по JPQL, что через Criteria API. Так что я бы не надеялся.

migesok
()
Ответ на: комментарий от Debasher

мне кажется в мало-мальски сложной логике юзаются субд-специфичные штуки которые всю 'универсальность' на нёт сводят

This.

БД-независимость вещь не бесплатная, даже с орм.

migesok
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.