RedBeanPHP — еще одна ORM библиотека

[@knekrasov]

Спасибо за статью.
Несколько вопросов:
#1 Насколько вменяемый получается результирующий SQL (кстати, можно ли его как-то увидеть в отладочном режиме)?
#2 Есть ли возможность декларативного задания отношения между сущностями (ассоциация, агрегация)?
#3 Как обстоят дела с управлением транзакциями?

[@sHinE]

#1 есть режим отладки, включается R::debug(true);
#2 насколько я понял, тут только между готовыми объектами можно задавать отношения. Или я ваш вопрос не понял.
#3 Про транзакции нашел только в wiki

[@RiderSx]

Я так понимаю эта ORM нужна для ознакомления с Active Record, ибо для продакшена она не годится :)

[@sHinE]

Насколько я понимаю, тут не Active Record (у объектов нет метода save() — их сохраняет другой объект). А продакшен — смотря какой продакшен. Я использовал первую версию в небольшой задачке, где пользователь заполнял довольно длинную форму и надо было все данные хранить в БД, чтобы потом пользователь мог продолжить заполнение или получить еще раз результат обработки своих данных. Там, как мне кажется, RedBeanPHP замечательно вписался с его import($_POST)

[@RiderSx]

Ну что-то вроде import($_POST) есть если не у всех ORM, то у многих :)
К примеру (Yii): $model->attributes = $_POST;

Хотя по поводу AR Вы все же правы, это больше похоже на DAO :)

[@ainu]

А Yii разве не сломается при добавлении нового инпута? Имею в виду ошибку mysql field not found.

[@AlexeyFrolov]

Подойдет для проектов на скорую руку.

[@JiLiZART]

для быстреньких штук самое оно, в закладки :)

[@Terion]

Не люблю ORM, но в этом что-то есть… Спасибо

[@amartynov]

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

Например, работа с ассоциациями мне сразу показалась подозрительной. С версии 1.3 до 2.0 все поменялось, но что тогда что сейчас все ассоциации выражены через many-to-many, что (на мой взгляд) чудовищно. Автор же считеат это преимуществом: мол вы можете ассоциировать что угодно с чем угодно. В версии 2.0 появились две странные фичи (nested beans и on-the-fly views) для тех, кому не нравилось, что любая ассоциация требует junction table.

То есть с одной стороны имеем тривиальный active record, и используем old good SQL (в старой доке была фраза «Some tools even promote their own version of SQL. To me this sounds incredibly stupid. Why should you use a system less powerful than the existing one? This is the reason that RedBean simply uses SQL as its search API.») С другой стороны, чтобы связать Product с Category приходится поступать куда более «incredibly stupid».

Для добавления логики к моделям используется нечто под названием «fuse» (данные и логика живут отдельно). На первый взгляд приколько, но на второй понимаешь, что от этого только проблемы (теряется инкапсуляция; тихо игнорируется вызов несуществующего метода...)

Напрягает наличие в базовой поставке каких-то экзотических вещей вроде Cooker и BeanCan Server.

RedBean может глотать исключения там, где этого делать не надо: tinyurl.com/c3yanmp
И один раз мне пришлось долго убеждать автора в том, что нельзя считать ноль и пустую строку эквивалентными данными: tinyurl.com/d6d3m8v

В целом у меня возникло ощущение, что RedBean — это полигон, на котором автор пробует всякие прикольные идеи, но большого доверия качество исполнения во мне не вызвало. Возможно, дело в том, что автор голландец и курит перед написанием кода…

Однако RedBean меня вдохновил, и я попытался сконцентрировать понравившиеся мне идеи в моем собственном проекте, который назвал orange-bean. Кому интересно, вот ссылка: code.google.com/p/orange-bean/

[@DeFacto]

Хотел поближе посмотреть на orange-bean…
А в чем смысл компресии вашего класса через php-compressor?
я думаю многие были бы благодарны, если исходник сразу был бы в удобно-читаемом виде.

[@amartynov]

Исходники не прячу: code.google.com/p/orange-bean/source/browse/#svn%2Ftrunk
Смысл — просто обкатываю компрессор (он тоже мой) на этом проекте.

[@AndrewStephanoff]

зачем вам обфускация? если нужно сжать в один файл — используйте phar с autoload

[@AlexeyFrolov]

Круто, но почему бы не следовать зендовым стандартам? framework.zend.com/manual/ru/coding-standard.coding-style.html.

[@LastDragon]

Вариант, что автор, как и я, не любит когда открывающая { расположена на новой строке, вас устраивает? :)

[@AlexeyFrolov]

Прошу принять во внимание, что это правило применимо только для классов и методов. Во всех остальных случаях { располагается на той же строке.

[@AlexeyFrolov]

Для меня решающим при выборе того или иного стандарта является его распространенность и не более.

[@LastDragon]

Для меня нет — если себя, то максимально приближенное к java code conventions, если существующий код, то по принятым в нём стандартам.

[@AlexeyFrolov]

На самом деле мне режет глаз то, что не camelCase…

[@LastDragon]

А ни у кого нет случайно списка PHP ORM, которые реализуют любой шаблон кроме ActiveRecord?
(приелось и хочется чего то более экзотического)

[@LastDragon]

За что минусуют? ActiveRecord не всегда удобно использовать да и кроме него есть еще несколько более сложных, но и более удобных шаблонов (data access object, table data gateway, row data gateway, data mapper и т.д.). Было бы интересно увидеть их реализацию.

[@taliban]

Подозреваю что минусуют за то, что в данном топике не ActiveRecord =)

[@LastDragon]

Хм, как не подумал о этом. Вопрос был задан безотносительно данного топика (собственно, этот топик на данный момент единственное место где могу задать подобный вопрос :().

[@VolCh]

Doctrine2 — DataMapper + ещё куча паттернов. Лично мне кажется самым удобным, т. к. классы и модели объектов самые обычные PHP-классы, никак не привязанные ни то что к схеме БД, но даже к системе хранения в целом.

[@bolk]

Если бы мы решили сохранить число в одном из свойств ($book->price = 100), то RedBeanPHP выбрал бы тип TINYINT(3) для хранения этого свойства. Если потом нам надо будет сохранить дробную цену, то RedBeanPHP на лету поменяет тип поля в БД.

Отсюда сразу следует, что это только для небольших игрушек. Где-нибудь не досмотрит программист, пропустит float и этот ОРМ начнёт шуршать таблицей, блокируя туда запись, перестраивая индекс, если таблица большая, это может повесить всё на минуты, а то и десятки минут.

[@sHinE]

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

[@bolk]

Спасибо. А как-то можно указать, что мне для текстовых данных мало varchar(255)?

[@amartynov]

Этого нельзя. Подразумевается, что после freeze вы внимательно посмотрите получившуюся схему и «расширите» типы колонок там, где получилось «мало»:
www.redbeanphp.com/manual/freeze

[@sHinE]

Я так понял, что bolk интересуется про тип поля до freeze(). В режиме fluid, я так думаю, RedBeanPHP должен уметь сохранять длинные текстовые данные.

[@amartynov]

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

[@satas]

А еще есть замечательная библиотека IdiORM
Мини- ORM, состоящий из одного файла. Очень рекомендую.