Обсуждаем Doctrine

[Rammstein]

Обсуждаем Doctrine

http://www.phpdoctrine.org/
Вроде бы заманчивая ORM, особенно учитывая неповоротливость ближайшего конкурента в лице Propel.
Кто использовал, какие впечатления?

 

[BlackSabbath]

Не использовал, но выглядит действительно очень заманчиво.

По документации которую я смотрел на их сайте возникло впечатление что делали глядя на Hibernate. А это безусловно к лучшему. Тоже с нетерпением жду отзывов.

 

[mani13]

Бегло просмотрев, ИМХО:

foreach($table->findBySql("name LIKE '%John%'") as $user)

Либо я чего-то не понял и LIKE используется как конструкция этого самого Doctrine, либо это всё-таки часть SQL-запроса.
Если второе, то чем это лучше какого-нибудь PDO?
Всё равно нет полного ухода от SQL...

P.S.: порадовало

Doctrine doesn't use XML so you don't have to study another xml-syntax.

Как будто XML что-то совершенно непонятное, имеющее в себе тысячи разных особенностей...
P.P.S.: а, вообще, надо потыкать, а то Propel действительно тяжёлый и подходит разве что для сайтов-игрушек.

 

[Rammstein]

mani13
Я такого кода в документации не заметил... Но в любом случае, это работа через $table, а возможна работа через Active Record самого объекта.

 

[bettrrr]

Тоже интересуют отзывы о Doctrine.
Для каких проектов используете?
Просто для высоко-нагруженного проекта - идея использовать ORM наверно не самая удачная, а для небольшого проекта проще всё написать руками.

ORM только для большого и сложного, но в то же время малопосещаемого???

 

[Wicked]

Что лично меня порадовало.
* структура базы данных является произведением от модели, поэтому деплоймент происходит на ура.
* Миграции. К сожалению, пока что без автогенерации на основании диффа двух схем/моделей.
* DQL. По сути пишешь тот же SQL, только он автоматом получается кроссбазный. Есть один проект, где я, когда разрабатываю на локалхосте, использу sqlite, чтобы не поднимать сервак. Причем DQL не обязательно писать в chaining-стиле.
* то, что это действительно ORM. Можно выполнить запрос типа

->from('Card c')
->innerJoin('c.CardRecipients as cr')
->addWhere('cr.to_id = ?', $this->getUser())
->addOrderBy('c.created_at DESC');

и автоматом получить коллекцию объектов Card, у которых в св-ве СardRecipients будут коллекции соответствующих объектов типа CardREcipient.
* Соответственно, класть в базу свзяанные между собой объекты так же просто.
* то, что doctrine по слухам скоро обещает стать стандартным ORM в symfony.
* использование YAML.
* CLI
* Поведения. Пока что использую только Timestampable.

Но пока что опыта работы с ним у меня крайне мало.

-~{}~ 30.11.07 13:33:

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

нелепое требование

 

[Bakti9rov]

Wicked

doctrine по слухам скоро обещает стать стандартным ORM в symfony.

контингент ниасилил Phing + Propel & Creole? =))

 

[syfisher]

Интересно, а кто нибудь ходил по ссылке, данной korchasa? Я чесно тогда потратил несколько дней на изучения Doctrine. Никто по этому поводу высказаться не хочет?

Еще раз ссылка:

http://forum.limb-project.com/viewtopic.php?p=9632#9632

Буду рад любым замечаниям...

 

[cDLEON]

Нужно будет заценить...
Интересная вещь по описанию....
[offtop]
давайте без оффтопа
[/offtop]

 

[HraKK]

2 All
Любой флуд не по теме, будет жестоко выкинут.

 

[atv]

syfisher

Так как PDOStatement не позволяет получить итератор, а возвращает весь набор данных сразу, такие фички, которые в Limb3 делаются "как 2 пальца", в Doctrine не проходят.

Можно подробнее, как именно сказывается отсутствие итератора?

По скорости : я тестировал добавление по 500 разных объектов двух классов и получение 500 объектов одного класса:

На какой машинке тестировали? Что-то очень большие значения времени...

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

Мы, например, заюзали Propel в текущем проекте, и у меня уже накопилось много камней за пазухой в его огород.

А всякие там цепочки из методов - это дело наживное и погоды не делает.

 

[syfisher]

atv

Мне сложно объяснить. Это лучше взлянуть на внутренную архитектуру Doctrine. У меня была задача - оценить возможность перехода на Doctrine и отказа от нашего DBAL + ActiveRecord пакетов.

В общем дело вот в чем - получая связанную коллекцию, Doctrine всегда делает мгновенный запрос, и уже к этому запросу лимитирование применять нельзя. Соответственно, все объекты тут же помещаются в память. Если нужно лимитирование или сортировка - придется писать DQL каждый раз - утомительно. Ну почему нельзя было возвращать proxy реализующий Iterator и который бы делал запрос в момет rewind()?

Ну и описание отношений - мне показалось нелогичным все под одну гребенку. Читать реально сложнее, чем аналоги из Rails или Limb3. Есть спорный случай для нескольких отношений one-to-one (такое ощущение, что все из Rails это копируют).

По скорости : тестировал на своей домашней машинке AthlonXp 2200+. Поэтому так медленно.

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

В общем для одних и тех же случаев Doctrine заставил меня писать больше кода, чем Limb3 ActiveRecord. А все, кроме eager fetching из Doctrine не сделает хорошей погоды для наших проектов. Поэтому решили подождать.

 

[Krishna]

syfisher
Тестировали вместе с memcached или без?

 

[syfisher]

Krishna

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

 

[Wicked]

syfisher
а традиционный sql за какое время справился? Ну т.е. чтобы совсем без ORM.

 

[syfisher]

Wicked
Не знаю. Можно еще разок протестить, чтобы относительные величины получить. Если я еще тест этот не убил... Хотя не проблема написать...

 

[Krishna]

syfisher
Я просто к тому, что может быть я ошибаюсь (никогда не использовал ORM в чистом виде), но как одно из преимуществ Doctrine я вижу прозрачную интеграцию с memcached. Возможно, Doctrine + memcached окажется даже более быстрым решением, чем чистый MySQL?

-~{}~ 05.12.07 18:22:

То есть, понятно, что чистый MySQL тоже можно использовать с Memcached, но там нужно всё реализовывать ручками, в отличие от...

 

[atv]

а традиционный sql за какое время справился?

а смысл такого теста, мы ведь не получим на выходе коллекцию объектов с соответствующим функционалом.

 

[korchasa]

Автор оригинала: Krishna
syfisher
Я просто к тому, что может быть я ошибаюсь (никогда не использовал ORM в чистом виде), но как одно из преимуществ Doctrine я вижу прозрачную интеграцию с memcached. Возможно, Doctrine + memcached окажется даже более быстрым решением, чем чистый MySQL?

Начнем с того, что кешей там 2:
кеш DQL->SQL, если не изменяет память используется массив, полученный из DQL, как id
кеш SQL->данные, данные - массив, следовательно получение из него коллекции будет происходить, даже если есть попадание в кеш случилось

Второй кеш относиться не к ORM, а к DBAL'у, и в принципе ничто не мешает использовать rawSQL, и получать инстансы объектов с помощью ORM. Не увурен, что в Doctrine есть такая фича, но ведь напильник есть у каждого .

В принципе DQL+DQLCache очень быстро отдает SQL. А если учесть, что rawSQL кешить нормально можно только денормализуя данные и усложняя операции create/update/delete, то Doctine смотриться в этом случае намного вкуснее.

Прозрачный кеш на больших нагрузках - зло, из-за того, что приходится использовать различные хранилища для кеша (файлы, БД, память) и разные способы управления (события, время, явные вызовы), причем они могут различаться даже внутри одного доменного объекта. Но это не оправдывает разработчиков Doctrine, которые реализовали только кеши на уровне соединения и на уровне запроса, пропустив объект (таблицу). В генерации страницы могут принимать участие и 5-10 разных кешей, а если они будут прозрачными, то там и концов не найдешь, если что-то кешироваться будет не так.

-~{}~ 06.12.07 03:57:

Ах вот зачем этот пост

 

[jonjonson]

Прежде чем обсуждать Doctrine, лучше бы ссылку на неё правильную выставили http://www.phpdoctrine.org/