Комрады!

Есть предложение обсудить перловые ORM, узнать слабые и сильные стороны разных библиотек. Мне необходимо провести их сравнение но разобраться со всеми - просто не 
реально..

Кто может высказать по следующим библиотекам?

Tangram
Rose:B::Object
Class::DBI
DBIx::Class
SPOPS
Hibernate (не перловая, но я думаю для сравнения нужно и ее описать)

Что бы удобнее было сравнивать оценивайте плиз следующие критерии:

0) удобство использования
1) возможность работать с готовыми классами без их изменения
2) возможность работать с готовой схемой БД без ее изменения
3) качество генерируемых схем (понятные имена таблиц и т.п.)
4) качество генерируемых запросов (скорость работы, тонкие места  SQL)
5) переносимость между БД
6) возможность встраивать свои код сохранения/загрузки
7) фичи библиотек..


Если есть дополнения к списку критериев, пишите. 

Ну что же никто не отвечает..

Приведу резалты нашего семинара по perl ORM.

SPOPS - умер давно, а в том который был было столько багов ( вплоть до незащищенности от injection). НЕ ЮЗАТЬ.

Class::DBI и DBIx::Class - внешне очень похожие фреймворки, второй есть улучшение первого (по крайней мере
так написано в доках) так что если изучать - то скорее сразу второй.
Эти фреймворки - есть ОБЕРТКА НАД БД. Т.е. в центре внимания лежит схема БД. Именно схема БД определяет структуру классов.
Как и все пакеты из Class::* Class::DBI сама создает необходимые мутаторы (и аксесоры) в классе по заданной таблице
Есть возможность писать SQL если не хватает возможностей ОРМ.
Плюсы: совместимость с готовой схемой БД. Идеально для построения Объектно-ориентированного интерфейса доступа к БД
Минусы: генерирует свои классы, Если уже есть классы моделирующие бизнес-сущности - нужно будет строить адаптеры и т.п.


Tangram - очень интересный ОРМ, советую обратить на него внимание..
Основная фича -  абсолютный отказ от SQL. Вам его просто не придется писать.
Вторая важная фича - ортогональность классам. Т.е. классы сохраняемые в базу ничего не знают о том что их сохраняют! 
нет необходимости наследоваться или добавлять методы. Мы можем сохранять готовые классы! Единственно ограничение - объекты должны быть ссылками на хэши.
Tangram сам генерирует схему БД с которой он будет работать. Поддерживает наследование.
Плюсы: очень удобно при разработке проекта с 0. Продумываете сложную бизнес - модель , и не парьтесь с БД.
Минусы: те же. Вы не контролируете схему БД, что иногда просто не приемлемо. Однако вы можете взять схему танграма и доработать "напильником"

Rose:B::Object - еще одна вариация на тему Class::DBI. Является частью веб - фреймворка Rose:: Пока еще находится в стадии разработки. сырой. Есть фича: удобный мультиплексор DBI соединений.

Большинство ОРМ в той или иной мере поддерживают Lazy Loading, кэширование.
Совместимость с БД - примерно одинаковая у всех MySQL, Postgres, SQLite, Oracte.
Некоторые держат Sybase (смотри доки)


Ну вот вообще и все что я хотел сказать. Кто может сравнить с этим Hibernate? 
отзывы типа "да хибернейт намного круче" принимаются, только пишите чем.

Про DBIx::Class. На самом деле  он может генерировать схему БД на основе классов. И даже делать diff-ы при изменении этих классов, правда тут он не поддерживает enum и вообще иногда ошибается, sql скрипты приходится иногда допиливать после него... Но работать с ним в стиле, когда структуру БД полностью определяет код, вполне можно.

Это сообщение отредактировал(а) Ромыч - 29.4.2008, 03:48

Есть такая штука PerlORM

http://search.cpan.org/~akimov/ORM-0.85/
http://sourceforge.net/projects/perlorm/

  

Это сообщение отредактировал(а) gcc - 19.11.2008, 06:50

понравлось пользоватся DBIx::Class

при построении программных запросов этой штукой разве удобно писать?

вродебы не спасает от удобства, все равно нужно писать, в принципе, одинаково... if elsif else

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

как еще такое можно написать?


Это сообщение отредактировал(а) gcc - 20.11.2008, 00:03

Возвращаясь к вопросу. Есть ли нормальные ORM под Perl? Пользовался DBIx::Class, однако он не аккуратно строит запросы. Во первых,  игнорирует выбор полей в prefetch, выбирая сразу все поля из всех таблиц. Во вторых добавляет в запрос странный "order by ключ таблицы", что при некоторых обстоятельствах приводит к провисанию базы. Еще меня не устраивает что join можно сделать только по заранее созданому правилу в Relationship, то есть нельзя выбрать inner join или outer join, только тот который в Relationship, хотя это меньшая проблема.

Нормальных ОРМ, сколько не искал, так и не нашел. Везде где то чего то не хватает.
Написал свой. Пользуюсь уже им 2 года, постоянно совершенствую его.
Вот его начинка: 
1. Обертка вокруг таблицы(DBI);
2. События наружу  типа просмотра, редактирования, добавления и др..;
3. В качетсве шаблонизатора HTML::Template
4. Класс который может компоновать обертки и делать общую(для представления нескольких таблиц в одной)
5. Чековалка на проверку ввода(потдерживает ajax запросы)
Вот вроде основное.. 

Это сообщение отредактировал(а) myth777 - 28.12.2010, 18:03

И что из этого ORM ? Это целый фреймворк =)

А можно на него посмотреть ? на CPAN выложен ?

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

Insert, update и простые select запросы можно писать в абстрации в какой-то... (SQL::Abstract, RoseDB, DBIx::Class, etc)
а все остальные в нативном виде, в /model/MySQL/table.pm
это не подходит?

Insert, update - пишутся в одну строку....
генератор простых SQL запросов, тоже, можно написать

есть сложные запросы в PostgreSQL, которые не написать в какой либо ORM

inner join на MySQL все пишут c пересечением по id:


Это сообщение отредактировал(а) gcc - 1.1.2011, 10:48