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



Опять врут и темнят? )
- нет, просто не обладают всей полнотой информации) Википедию пишут обычные люди, не всегда обладающие нужными экспертными знаниями. Скажите честно, до того как я написал абревиатуру JDOQL Вы про нее знали или вспоминали (это я не для того чтобы обидеть, а для примера)? Уверен что ни автор статьи, ни его читатели не участвовали в создании спецификации JPA и разработке Hibernate, именно по этому история темная. Или к примеру тот же Hibernate - ведь наверняка уверены, что до него ничего не было? В то время как TopLink был портирован на Java в 1998 со Smalltalk. Или также появившийся в начале 2000х Apache Cayenne. И т д. Идеи и настроения витали в воздухе, поэтому лично я утверждать что спецификацию JPA сделали именно на основе Hibernate не стал бы. Ниже интересная цитата из книги "Persistence in the Enterprise: A Guide to Persistence Technologies":

- в большинстве проектов работают в рамках JPA (а хинты выносят в настройки), поэтому смена ORM проходит достаточно легко (проблемы там где делают unwrap и хардкодят хинты - но ... сами понимаете, это по сути дурной тон кодирования). Хотя, если быть честным, в большинстве проектов используют Hibernate и никаких предпосылок использовать что то иное нет)

- я бы сформулировал иначе) Говорим ORM, подразумеваем JPA (хотя есть крупные EE проекты где работают без JPA - например Diasoft в некоторых своих широко внедренных проектах использует Apache Cayenne или Google App Engine, где применяют JDO, есть и проекты на iBATIS).

- не стоит создавать мифы (и ограничивать кругозор). Тем кто начинал свой путь с Hibernate, сложнее, так как особой необходимости копаться в альтернативах и истории нет, тем кто видел как это Hibernate появился, проще, так как уже все альтернативы попробованы.


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

- что может быть лучше Native SQL в смысле производительности? (вопрос провакациононный)

- какой то беспредметный наезд. Я работал в разных проектах (в том числе ... бла-бла-бла ... сейчас это ЕМИАС) и нативные запросы, необходимость их оптимизации и пятиэтажные джойны с позапросами - не редкость (и эффект на производительность бывает более чем существенным). Лично я не считаю что native sql -это правильный путь однако плевать на производительность даже PetShop глупо. Когда дебильный код работает у разраба на трех записях в базе - это не значит что он будет так же хорошо работать на нескольких миллионах записей на проде. В ЕМИАС, например, записей довольно много а скорость выполнения запроса (метода) это критический параметр который лимитируется, а вот кластеризация "утюга", к сожалению, не повышает скорость выполнения отдельных методов, что накладывает обязательства на архитектора и разработчика, так как тупым увеличением мощности железа вопрос не решается

- Вы зачем то начали форсить тему "кто на ком стоял", я Вас поправил, что история более сложная чем это написал хз кто в википедии. Если для Вас это важно, можно дискутировать дальше, хотя мне этот вопрос кажется не существенным.