Комментарии 47
Сюда бы ещё хабракат....
0
Я так и не понял, как в Зенд_Тейбл делать нечто типа (LEFT) JOIN. Насколько понял по мануалу, связи таблиц - это что-то не то.
0
На самом деле - еще есть вещи, коотрые бы можно было добавить, чтобы они работали автоматически:
- Возможность сразу fetch'ить данные из нескольких таблиц
Написано-же...
- Возможность сразу fetch'ить данные из нескольких таблиц
Написано-же...
0
Получить такие данные вполне можно - через саму базу данных (а точнее - через драйвер к ней), но засовывать эти данные по обьектам таблиц прийдется вручную.
0
Ну понятно, что через адаптер к зенд_селект можно что угодно написать. А хотелось бы именно абстракцию, которой указал какие таблицы какими столбцами джойнить, а она дает готовый объект-таблицу.
0
Ну, это ж не ORM полноценный. Скорее - удобная обертка над бд. Нужно что-то покруче - Propel, Doctrine. :)
PS. Я могу ошибаться насчет невозможности изначальных join'ов - я в Zend_Db не спец (я больше по Symfony + Propel), но по-моему их всё-таки нет. :)
PS. Я могу ошибаться насчет невозможности изначальных join'ов - я в Zend_Db не спец (я больше по Symfony + Propel), но по-моему их всё-таки нет. :)
0
А Zend_Db_Table_Select не позволяет?
0
Получаете у таблицы адаптер, у него берете селект и у селекта есть необходимые методы.
Вот пример:
$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.
0
угу. А в итоге я не получу ни Zend_Db_Table_Row, ни Zend_Db_Table_Rowset, о чем мы и говорили.
0
В последних версиях 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 :)
0
Все понятно, и даже то, что "разобрать результат по объектам" тоже, но выглядит много сложнее простого 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, возможно поменяю мнение...
0
Написал свою простенькую ORM. Получилось правда коряво, при запросах нужно явно указывать, какие модели джойнятся. Но работает.
0
Использую Zend_Db_Table в своем текущем проекте. Инструмент достаточно хороший, но имеет кучу недостатков:
- работа со связями один-ко-многим, многие-ко-многим реализована только на уровне выборки (да и то только по id);
- при выборке и записе дата принимается и возвращается как строка в формате БД что доставляет кучу проблем;
- при даже простых выборках из таблицы приходится скатываться до селектов, с учетом того что они на порядок не удобнее того же filter в Django.
- при джойнах достаточно странно ведет себя (больше, наверно относится к Zend_Db_Select).
0
НЛО прилетело и опубликовало эту надпись здесь
Да, Вы правы, именно из-за этого он так и ругается ))
0
не совсем так, точный код не приведу но суть примерно такая:
В этом случае, без указания from, left join чудесным образом превращается в inner.
Если интересно могу посмотреть конкретный запрос где это происходит.
$select = Table_A->select()
->joinLeft('b', 'b.id = A.b', array())
->where('b.x = ?', y);
В этом случае, без указания from, left join чудесным образом превращается в inner.
Если интересно могу посмотреть конкретный запрос где это происходит.
0
пробовал вчера джойны - все нормально работает, по крайней мере те самые частые - левые.
ZF во время обучения конечно бывает очень сложен, но зато позже одно удовольствие.
ZF во время обучения конечно бывает очень сложен, но зато позже одно удовольствие.
0
не сказать что ZF сложен, скорее напрягает его "нецелостность" - одно и тоже действие можно сделать 2-4 способами, и нет даже подсказки какой лучше.
Django, например, достаточно целостный и весь фреймворк пронизывает некий стиль, общее удобство.
Django, например, достаточно целостный и весь фреймворк пронизывает некий стиль, общее удобство.
0
Выбирал фактически не я, да и переписывать уже поздновато.
Не подумайте что затеваю холивар, но пайтон и джанго мне нравятся гораздо, больше. PHP похож на свалку функций, коллекцию костылей и подпорок, даже нормального класса для работы с датой нет, нет filter для итерируемых объектов и create_function достаточно неудобен.
Надеюсь с выходом шестой версии PHP 6 станет лучше и избавится от исторического мусора.
Не подумайте что затеваю холивар, но пайтон и джанго мне нравятся гораздо, больше. PHP похож на свалку функций, коллекцию костылей и подпорок, даже нормального класса для работы с датой нет, нет filter для итерируемых объектов и create_function достаточно неудобен.
Надеюсь с выходом шестой версии PHP 6 станет лучше и избавится от исторического мусора.
0
НЛО прилетело и опубликовало эту надпись здесь
Да PHP вообще шлак, а Zend Framework никогда бы не был написан, не появись в свое время RoR.
-7
Судя по минусам, вижу, что кто-то готов опровергнуть мое утверждение?
-1
Вообщем так, мелкие тупоголовые пидорасы, меня основательно заебало ваше тупорылое молчание. Поэтому слушайте внимательно, черви. Если вы не в состоянии осознать каличность такого недоязыка как PHP, то мне вас искренне жаль. PHP - это тупиковая ветвь, которая едва ли когда-нибудь догонит тот же Javascript по элегантности: слишком много косяков было допущено в 3-й версии PHP, и они до сих пор дают о себе знать. Если вы до сих пор не смогли ощутить ущербность языка и кривость реализации, значит вы вообще нихрена не шарите в программировании.
Впрочем, нет. Никакой жалости к вам я не испытываю. Пишите, пишите дальше свои ущербные скриптишки, ОРМы, Хуермы и прочую поебень. Однажды вы осознаете, что благодаря ПЭ-ХА-ПЭ вы перестали быть программистами и способны не более чем CRUDить примитивные типы данных в очередном супер-пупер-мега-проекте.
ЗЫ. Хабр превратился в клуб малолетних неадекватов, кричащих "супер-супер! дайте еще!". Здесь практически не осталось вменяемых перцев, за исключением, пожалуй, khim'а. И даже наступая в говно, вы будете успокаивать себя, что это вовсе не говно, а такой гламурный шоколад и вообще все идет пучком. ага.
Впрочем, нет. Никакой жалости к вам я не испытываю. Пишите, пишите дальше свои ущербные скриптишки, ОРМы, Хуермы и прочую поебень. Однажды вы осознаете, что благодаря ПЭ-ХА-ПЭ вы перестали быть программистами и способны не более чем CRUDить примитивные типы данных в очередном супер-пупер-мега-проекте.
ЗЫ. Хабр превратился в клуб малолетних неадекватов, кричащих "супер-супер! дайте еще!". Здесь практически не осталось вменяемых перцев, за исключением, пожалуй, khim'а. И даже наступая в говно, вы будете успокаивать себя, что это вовсе не говно, а такой гламурный шоколад и вообще все идет пучком. ага.
-1
Вот не надо, документация в Zend Framework сделана на отлично и навигация очень удобная и очень фрагментированая. Для каждой главы, десятки подразделов. Да и API отлично описано.
0
... и вновь хочется сказать: "ты просто ищешь Django, %username%"
-3
ZF, конечно, тяжеловесный. Лично я в последнее время остановился на следующем варианте: примитивный ActiveRecord + QueryObject (а-я RoR, работает только под PHP-5.3+, благо проект позволяет использовать новейшие версии языка с их возможностями). Но! Если мне нужен более-менее сложный запрос - я пишу его ручками, не доверяя никаким конструкторам запросов. QueryObject же использую в сложных запросах только в том случае, если необходимо динамическое формирование различных фильтров в зависимости от запроса пользователя (QueryObject в данном случае гораздо удобнее, чем непосредственно конструировать каждый такой запрос). В моем случае я обошелся всего 2мя базовыми классами ActiveRecord & Query, не делал никаких абстракций от БД (вполне достаточно PDO с его массой возможностей). Если кому-то интересно, могу дать ссылку на СВН-репозиторий, проект доступен в открытых источниках.
0
Интересно. Давай.
0
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. Если кого действительно заинтересует все это добро - помогу разобраться, можно выйти на связь по аське или почте.
0
Я бы сейчас не стал использовать PHP 5.3 в продакшене. А если не использовать LSB оттуда - прийдется вводить абстракцию таблицы для того, чтобы это всё нормально работало с полиморфизмом и наследованием. :)
Иначе приходится в везде указывать имя класса, с которым работаем, т.е. получается что-то типа:
Articles::find('Articles')
Что в итоге в кодах исходного AR превращается в ужас в саппорте. Именно поэтому удобно это всё вынести в класс таблицы.
Иначе приходится в везде указывать имя класса, с которым работаем, т.е. получается что-то типа:
Articles::find('Articles')
Что в итоге в кодах исходного AR превращается в ужас в саппорте. Именно поэтому удобно это всё вынести в класс таблицы.
-1
Для 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 в продакшене в проекте, предназначенном для внутренних нужд моей компании - работает второй месяц без сбоев (впрочем, как вы понимаете, нагрузок нет).
0
Спасибо, жаль что не понятно сколько ждать релиза пхп версии 5.3 :)
А так вообще классно всё!
А так вообще классно всё!
0
Ай яй яй :-) Сделали бы, к примеру, inaf - было бы "inaf is not framework" :-) Ъ
0
зф классная штука. но зенд_тейбл жутковат
чтобы использовать, стоит как минимум прописать кеширование метаинформации о таблице (благо, это в пару строк делается), иначе он каждый раз запрашивать будет при создании обьекта
кстати, как раз думал написать что-нибудь про зф: например, как я с его помощью сегодня поднял опенид-сервер на моем проекте (там не очень вышло сделать, как в скудных примерах из доков). но ломает как-то :)
чтобы использовать, стоит как минимум прописать кеширование метаинформации о таблице (благо, это в пару строк делается), иначе он каждый раз запрашивать будет при создании обьекта
кстати, как раз думал написать что-нибудь про зф: например, как я с его помощью сегодня поднял опенид-сервер на моем проекте (там не очень вышло сделать, как в скудных примерах из доков). но ломает как-то :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
Использование Zend_Db_Table