Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
Сюда бы ещё хабракат....
Я так и не понял, как в Зенд_Тейбл делать нечто типа (LEFT) JOIN. Насколько понял по мануалу, связи таблиц - это что-то не то.
На самом деле - еще есть вещи, коотрые бы можно было добавить, чтобы они работали автоматически:
- Возможность сразу fetch'ить данные из нескольких таблиц
Написано-же...
- Возможность сразу fetch'ить данные из нескольких таблиц
Написано-же...
Получить такие данные вполне можно - через саму базу данных (а точнее - через драйвер к ней), но засовывать эти данные по обьектам таблиц прийдется вручную.
Ну понятно, что через адаптер к зенд_селект можно что угодно написать. А хотелось бы именно абстракцию, которой указал какие таблицы какими столбцами джойнить, а она дает готовый объект-таблицу.
А 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.
Вот пример:
$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 :)
Но тут есть несколько НО:
Во-первых, если в нескольких таблицах есть поля с одинаковыми именами - они перезапишутся друг другом, поэтому нужно давать полям псевдонимы.
Во-вторых, в при таком вызове: $mUser->fetchAll($select) будет возвращен объект строки таблицы, которая является главной: ... ->from(array('u' => $mUser->getTableName()) ... то бишь, я получу Zend_Db_Table_Row таблицы User :)
Все понятно, и даже то, что "разобрать результат по объектам" тоже, но выглядит много сложнее простого plain-select'а.
Лично мне думается, что это перегиб, можно ведь для простых запросов использовать "$record = $table->fetchOneWhere("slug = 'hello'");" Но таких запросов очень небольшой %, а большие приятнее как: "$record = $table->fetchAllByQuery("select ... left join ... where slug = 'hello', ...");"
Выходит _значительное_ перепрятывание sql'а за сложные конструктивные манипуляции объектами?
p.s. Еще конечно перечитаю что там с Zend_Db_Table, возможно поменяю мнение...
Лично мне думается, что это перегиб, можно ведь для простых запросов использовать "$record = $table->fetchOneWhere("slug = 'hello'");" Но таких запросов очень небольшой %, а большие приятнее как: "$record = $table->fetchAllByQuery("select ... left join ... where slug = 'hello', ...");"
Выходит _значительное_ перепрятывание sql'а за сложные конструктивные манипуляции объектами?
p.s. Еще конечно перечитаю что там с Zend_Db_Table, возможно поменяю мнение...
Почитай про Doctrine, поймешь, о чем я.
Написал свою простенькую ORM. Получилось правда коряво, при запросах нужно явно указывать, какие модели джойнятся. Но работает.
Использую Zend_Db_Table в своем текущем проекте. Инструмент достаточно хороший, но имеет кучу недостатков:
- работа со связями один-ко-многим, многие-ко-многим реализована только на уровне выборки (да и то только по id);
- при выборке и записе дата принимается и возвращается как строка в формате БД что доставляет кучу проблем;
- при даже простых выборках из таблицы приходится скатываться до селектов, с учетом того что они на порядок не удобнее того же filter в Django.
- при джойнах достаточно странно ведет себя (больше, наверно относится к Zend_Db_Select).
Да, Вы правы, именно из-за этого он так и ругается ))
не совсем так, точный код не приведу но суть примерно такая:
В этом случае, без указания from, left join чудесным образом превращается в inner.
Если интересно могу посмотреть конкретный запрос где это происходит.
$select = Table_A->select()
->joinLeft('b', 'b.id = A.b', array())
->where('b.x = ?', y);
В этом случае, без указания from, left join чудесным образом превращается в inner.
Если интересно могу посмотреть конкретный запрос где это происходит.
пробовал вчера джойны - все нормально работает, по крайней мере те самые частые - левые.
ZF во время обучения конечно бывает очень сложен, но зато позже одно удовольствие.
ZF во время обучения конечно бывает очень сложен, но зато позже одно удовольствие.
не сказать что ZF сложен, скорее напрягает его "нецелостность" - одно и тоже действие можно сделать 2-4 способами, и нет даже подсказки какой лучше.
Django, например, достаточно целостный и весь фреймворк пронизывает некий стиль, общее удобство.
Django, например, достаточно целостный и весь фреймворк пронизывает некий стиль, общее удобство.
Выбирал фактически не я, да и переписывать уже поздновато.
Не подумайте что затеваю холивар, но пайтон и джанго мне нравятся гораздо, больше. PHP похож на свалку функций, коллекцию костылей и подпорок, даже нормального класса для работы с датой нет, нет filter для итерируемых объектов и create_function достаточно неудобен.
Надеюсь с выходом шестой версии PHP 6 станет лучше и избавится от исторического мусора.
Не подумайте что затеваю холивар, но пайтон и джанго мне нравятся гораздо, больше. PHP похож на свалку функций, коллекцию костылей и подпорок, даже нормального класса для работы с датой нет, нет filter для итерируемых объектов и create_function достаточно неудобен.
Надеюсь с выходом шестой версии PHP 6 станет лучше и избавится от исторического мусора.
Да PHP вообще шлак, а Zend Framework никогда бы не был написан, не появись в свое время RoR.
Судя по минусам, вижу, что кто-то готов опровергнуть мое утверждение?
Вообщем так, мелкие тупоголовые пидорасы, меня основательно заебало ваше тупорылое молчание. Поэтому слушайте внимательно, черви. Если вы не в состоянии осознать каличность такого недоязыка как PHP, то мне вас искренне жаль. PHP - это тупиковая ветвь, которая едва ли когда-нибудь догонит тот же Javascript по элегантности: слишком много косяков было допущено в 3-й версии PHP, и они до сих пор дают о себе знать. Если вы до сих пор не смогли ощутить ущербность языка и кривость реализации, значит вы вообще нихрена не шарите в программировании.
Впрочем, нет. Никакой жалости к вам я не испытываю. Пишите, пишите дальше свои ущербные скриптишки, ОРМы, Хуермы и прочую поебень. Однажды вы осознаете, что благодаря ПЭ-ХА-ПЭ вы перестали быть программистами и способны не более чем CRUDить примитивные типы данных в очередном супер-пупер-мега-проекте.
ЗЫ. Хабр превратился в клуб малолетних неадекватов, кричащих "супер-супер! дайте еще!". Здесь практически не осталось вменяемых перцев, за исключением, пожалуй, khim'а. И даже наступая в говно, вы будете успокаивать себя, что это вовсе не говно, а такой гламурный шоколад и вообще все идет пучком. ага.
Впрочем, нет. Никакой жалости к вам я не испытываю. Пишите, пишите дальше свои ущербные скриптишки, ОРМы, Хуермы и прочую поебень. Однажды вы осознаете, что благодаря ПЭ-ХА-ПЭ вы перестали быть программистами и способны не более чем CRUDить примитивные типы данных в очередном супер-пупер-мега-проекте.
ЗЫ. Хабр превратился в клуб малолетних неадекватов, кричащих "супер-супер! дайте еще!". Здесь практически не осталось вменяемых перцев, за исключением, пожалуй, khim'а. И даже наступая в говно, вы будете успокаивать себя, что это вовсе не говно, а такой гламурный шоколад и вообще все идет пучком. ага.
Вот не надо, документация в Zend Framework сделана на отлично и навигация очень удобная и очень фрагментированая. Для каждой главы, десятки подразделов. Да и API отлично описано.
... и вновь хочется сказать: "ты просто ищешь 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. Если кого действительно заинтересует все это добро - помогу разобраться, можно выйти на связь по аське или почте.
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 превращается в ужас в саппорте. Именно поэтому удобно это всё вынести в класс таблицы.
Иначе приходится в везде указывать имя класса, с которым работаем, т.е. получается что-то типа:
Articles::find('Articles')
Что в итоге в кодах исходного AR превращается в ужас в саппорте. Именно поэтому удобно это всё вынести в класс таблицы.
Для php-5.3 я создал в репозитории бранч, а для предыдущих версий имеется trunk, в котором как раз все так и обстоит: отдельно класс таблицы данных и Активная запись, которая этот класс таблицы использует.
Отдельно по поводу "Я бы сейчас не стал использовать PHP 5.3 в продакшене". Действительно, боязно, и никакой админ не станет ставить его для серьзного нагруженного проекта. И тем не менее:
1. Разработчики PHP Маркус Бёргер и Дмитрий Стогов в личной беседе высказали мнение, что PHP 5.3 сегодня стабильнее, нежели 5.2.x.
2. Релиз, вероятно, будет уже этим летом (кстати, это - в ответ на следующий комментарий)
3. Лично я использую PHP 5.3 в продакшене в проекте, предназначенном для внутренних нужд моей компании - работает второй месяц без сбоев (впрочем, как вы понимаете, нагрузок нет).
Отдельно по поводу "Я бы сейчас не стал использовать PHP 5.3 в продакшене". Действительно, боязно, и никакой админ не станет ставить его для серьзного нагруженного проекта. И тем не менее:
1. Разработчики PHP Маркус Бёргер и Дмитрий Стогов в личной беседе высказали мнение, что PHP 5.3 сегодня стабильнее, нежели 5.2.x.
2. Релиз, вероятно, будет уже этим летом (кстати, это - в ответ на следующий комментарий)
3. Лично я использую PHP 5.3 в продакшене в проекте, предназначенном для внутренних нужд моей компании - работает второй месяц без сбоев (впрочем, как вы понимаете, нагрузок нет).
Спасибо, жаль что не понятно сколько ждать релиза пхп версии 5.3 :)
А так вообще классно всё!
А так вообще классно всё!
Ай яй яй :-) Сделали бы, к примеру, inaf - было бы "inaf is not framework" :-) Ъ
зф классная штука. но зенд_тейбл жутковат
чтобы использовать, стоит как минимум прописать кеширование метаинформации о таблице (благо, это в пару строк делается), иначе он каждый раз запрашивать будет при создании обьекта
кстати, как раз думал написать что-нибудь про зф: например, как я с его помощью сегодня поднял опенид-сервер на моем проекте (там не очень вышло сделать, как в скудных примерах из доков). но ломает как-то :)
чтобы использовать, стоит как минимум прописать кеширование метаинформации о таблице (благо, это в пару строк делается), иначе он каждый раз запрашивать будет при создании обьекта
кстати, как раз думал написать что-нибудь про зф: например, как я с его помощью сегодня поднял опенид-сервер на моем проекте (там не очень вышло сделать, как в скудных примерах из доков). но ломает как-то :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование Zend_Db_Table