Pull to refresh

Comments 47

А вы еще разок посмотрите ;)
Я так и не понял, как в Зенд_Тейбл делать нечто типа (LEFT) JOIN. Насколько понял по мануалу, связи таблиц - это что-то не то.
На самом деле - еще есть вещи, коотрые бы можно было добавить, чтобы они работали автоматически:
- Возможность сразу fetch'ить данные из нескольких таблиц

Написано-же...
Получить такие данные вполне можно - через саму базу данных (а точнее - через драйвер к ней), но засовывать эти данные по обьектам таблиц прийдется вручную.
Ну понятно, что через адаптер к зенд_селект можно что угодно написать. А хотелось бы именно абстракцию, которой указал какие таблицы какими столбцами джойнить, а она дает готовый объект-таблицу.
Ну, это ж не ORM полноценный. Скорее - удобная обертка над бд. Нужно что-то покруче - Propel, Doctrine. :)

PS. Я могу ошибаться насчет невозможности изначальных join'ов - я в Zend_Db не спец (я больше по Symfony + Propel), но по-моему их всё-таки нет. :)
Эх, знакомили меня вчера с докториной
Так я и не понял зачем это.
Раскажите пожалуйста :) Удобность не упоминать, лично мне так не удобно:)
А Zend_Db_Table_Select не позволяет?
А ты попробуй. ;) Нет, не позволяет.
Получаете у таблицы адаптер, у него берете селект и у селекта есть необходимые методы.
Вот пример:
$select = $mMeetStat->select()->setIntegrityCheck(false)
->from(array('u' => $mUser->getTableName()), array('id_user', 'nickname', 'age', 'date_reg', 'sex', 'photo_hash')),
->joinLeft(array('ms' => $mMeetStat->getTableName()), '(u.id_user = ms.id_user_to) OR (u.id_user = ms.id_user_from)')
->where('...');

$mUser и $mMeetingStat - объекты Zend_Db_Table.
угу. А в итоге я не получу ни Zend_Db_Table_Row, ни Zend_Db_Table_Rowset, о чем мы и говорили.
В последних версиях ZF вы можете подставить этот селект в метод fetchAll() объекта таблицы, в итоге получите как раз Zend_Db_Table_Rowset и внутри будут Zend_Db_Table_Row, соответственно с методами, объявленными вами в наследуемом от Zend_Db_Table_Row классе и членами-полями в таблицах.
Но тут есть несколько НО:
Во-первых, если в нескольких таблицах есть поля с одинаковыми именами - они перезапишутся друг другом, поэтому нужно давать полям псевдонимы.
Во-вторых, в при таком вызове: $mUser->fetchAll($select) будет возвращен объект строки таблицы, которая является главной: ... ->from(array('u' => $mUser->getTableName()) ... то бишь, я получу Zend_Db_Table_Row таблицы User :)
Ок. А что оно будет делать с related_tables? :)
А ничего:) Просто в возвращаемом объекте строки будут дополнительные поля из related_tables )
Я извиняюсь, но это абсолютно не то, о чем я говорю. И "такое" мне явно не нужно.
Я извиняюсь, значит я вас не так понял :)
Все понятно, и даже то, что "разобрать результат по объектам" тоже, но выглядит много сложнее простого plain-select'а.

Лично мне думается, что это перегиб, можно ведь для простых запросов использовать "$record = $table->fetchOneWhere("slug = 'hello'");" Но таких запросов очень небольшой %, а большие приятнее как: "$record = $table->fetchAllByQuery("select ... left join ... where slug = 'hello', ...");"

Выходит _значительное_ перепрятывание sql'а за сложные конструктивные манипуляции объектами?

p.s. Еще конечно перечитаю что там с Zend_Db_Table, возможно поменяю мнение...
Написал свою простенькую ORM. Получилось правда коряво, при запросах нужно явно указывать, какие модели джойнятся. Но работает.
Использую Zend_Db_Table в своем текущем проекте. Инструмент достаточно хороший, но имеет кучу недостатков:

  • работа со связями один-ко-многим, многие-ко-многим реализована только на уровне выборки (да и то только по id);

  • при выборке и записе дата принимается и возвращается как строка в формате БД что доставляет кучу проблем;

  • при даже простых выборках из таблицы приходится скатываться до селектов, с учетом того что они на порядок не удобнее того же filter в Django.

  • при джойнах достаточно странно ведет себя (больше, наверно относится к Zend_Db_Select).

UFO landed and left these words here
Да, Вы правы, именно из-за этого он так и ругается ))
не совсем так, точный код не приведу но суть примерно такая:

$select = Table_A->select()
->joinLeft('b', 'b.id = A.b', array())
->where('b.x = ?', y);

В этом случае, без указания from, left join чудесным образом превращается в inner.

Если интересно могу посмотреть конкретный запрос где это происходит.
пробовал вчера джойны - все нормально работает, по крайней мере те самые частые - левые.
ZF во время обучения конечно бывает очень сложен, но зато позже одно удовольствие.
не сказать что ZF сложен, скорее напрягает его "нецелостность" - одно и тоже действие можно сделать 2-4 способами, и нет даже подсказки какой лучше.

Django, например, достаточно целостный и весь фреймворк пронизывает некий стиль, общее удобство.
Ну так не используйте его как фреймворк. :)

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

Не подумайте что затеваю холивар, но пайтон и джанго мне нравятся гораздо, больше. PHP похож на свалку функций, коллекцию костылей и подпорок, даже нормального класса для работы с датой нет, нет filter для итерируемых объектов и create_function достаточно неудобен.

Надеюсь с выходом шестой версии PHP 6 станет лучше и избавится от исторического мусора.
Да я как бы ни против руби, ни против питона ничего не имею. :)
UFO landed and left these words here
Да PHP вообще шлак, а Zend Framework никогда бы не был написан, не появись в свое время RoR.
Судя по минусам, вижу, что кто-то готов опровергнуть мое утверждение?
Вообщем так, мелкие тупоголовые пидорасы, меня основательно заебало ваше тупорылое молчание. Поэтому слушайте внимательно, черви. Если вы не в состоянии осознать каличность такого недоязыка как PHP, то мне вас искренне жаль. PHP - это тупиковая ветвь, которая едва ли когда-нибудь догонит тот же Javascript по элегантности: слишком много косяков было допущено в 3-й версии PHP, и они до сих пор дают о себе знать. Если вы до сих пор не смогли ощутить ущербность языка и кривость реализации, значит вы вообще нихрена не шарите в программировании.

Впрочем, нет. Никакой жалости к вам я не испытываю. Пишите, пишите дальше свои ущербные скриптишки, ОРМы, Хуермы и прочую поебень. Однажды вы осознаете, что благодаря ПЭ-ХА-ПЭ вы перестали быть программистами и способны не более чем CRUDить примитивные типы данных в очередном супер-пупер-мега-проекте.

ЗЫ. Хабр превратился в клуб малолетних неадекватов, кричащих "супер-супер! дайте еще!". Здесь практически не осталось вменяемых перцев, за исключением, пожалуй, khim'а. И даже наступая в говно, вы будете успокаивать себя, что это вовсе не говно, а такой гламурный шоколад и вообще все идет пучком. ага.
Вот не надо, документация в Zend Framework сделана на отлично и навигация очень удобная и очень фрагментированая. Для каждой главы, десятки подразделов. Да и API отлично описано.
Вы не поняли мою мысль. Да, возможно ZF докрутили до состояния вменяемости. Но волшебный пеньдель зендовцам под зад (и еще кое-кому) дали разработчики Ruby On Rails. Не появись RoR - не было бы и ZF.
RoR не единственный фреймворк. И не первый. ;)
Не единственный, но если прокрутить историю PHP на пару-тройку лет назад, что мы увидим? :)
... и вновь хочется сказать: "ты просто ищешь Django, %username%"
ZF, конечно, тяжеловесный. Лично я в последнее время остановился на следующем варианте: примитивный ActiveRecord + QueryObject (а-я RoR, работает только под PHP-5.3+, благо проект позволяет использовать новейшие версии языка с их возможностями). Но! Если мне нужен более-менее сложный запрос - я пишу его ручками, не доверяя никаким конструкторам запросов. QueryObject же использую в сложных запросах только в том случае, если необходимо динамическое формирование различных фильтров в зависимости от запроса пользователя (QueryObject в данном случае гораздо удобнее, чем непосредственно конструировать каждый такой запрос). В моем случае я обошелся всего 2мя базовыми классами ActiveRecord & Query, не делал никаких абстракций от БД (вполне достаточно PDO с его массой возможностей). Если кому-то интересно, могу дать ссылку на СВН-репозиторий, проект доступен в открытых источниках.
Интересно. Давай.
svn checkout http://svn.berlios.de/svnroot/repos/naf/branches/php-5.3/ naf-php-5.3

Naf - моя библиотека, название расшифровывается как "Not A Framework". ActiveRecord.php и Query.php лежат в папке db (и в неймспейсе naf::db). Кроме того, для работы ActiveRecord требуется naf::util::Validator, файл util/Validator.php. Если кого действительно заинтересует все это добро - помогу разобраться, можно выйти на связь по аське или почте.
Я бы сейчас не стал использовать PHP 5.3 в продакшене. А если не использовать LSB оттуда - прийдется вводить абстракцию таблицы для того, чтобы это всё нормально работало с полиморфизмом и наследованием. :)

Иначе приходится в везде указывать имя класса, с которым работаем, т.е. получается что-то типа:
Articles::find('Articles')

Что в итоге в кодах исходного AR превращается в ужас в саппорте. Именно поэтому удобно это всё вынести в класс таблицы.
Для php-5.3 я создал в репозитории бранч, а для предыдущих версий имеется trunk, в котором как раз все так и обстоит: отдельно класс таблицы данных и Активная запись, которая этот класс таблицы использует.

Отдельно по поводу "Я бы сейчас не стал использовать PHP 5.3 в продакшене". Действительно, боязно, и никакой админ не станет ставить его для серьзного нагруженного проекта. И тем не менее:
1. Разработчики PHP Маркус Бёргер и Дмитрий Стогов в личной беседе высказали мнение, что PHP 5.3 сегодня стабильнее, нежели 5.2.x.
2. Релиз, вероятно, будет уже этим летом (кстати, это - в ответ на следующий комментарий)
3. Лично я использую PHP 5.3 в продакшене в проекте, предназначенном для внутренних нужд моей компании - работает второй месяц без сбоев (впрочем, как вы понимаете, нагрузок нет).
Спасибо, жаль что не понятно сколько ждать релиза пхп версии 5.3 :)
А так вообще классно всё!
Ай яй яй :-) Сделали бы, к примеру, inaf - было бы "inaf is not framework" :-) Ъ
зф классная штука. но зенд_тейбл жутковат
чтобы использовать, стоит как минимум прописать кеширование метаинформации о таблице (благо, это в пару строк делается), иначе он каждый раз запрашивать будет при создании обьекта

кстати, как раз думал написать что-нибудь про зф: например, как я с его помощью сегодня поднял опенид-сервер на моем проекте (там не очень вышло сделать, как в скудных примерах из доков). но ломает как-то :)
Only those users with full accounts are able to leave comments. Log in, please.