fxposter Jul 21 2008 at 00:06

Использование Zend_Db_Table

3 min

2.6K

Zend Framework*

Comments 47

ruskar Jul 21 2008 at 00:08

Сюда бы ещё хабракат....

fxposter Jul 21 2008 at 00:09

А вы еще разок посмотрите ;)

TMC Jul 21 2008 at 00:21

Я так и не понял, как в Зенд_Тейбл делать нечто типа (LEFT) JOIN. Насколько понял по мануалу, связи таблиц - это что-то не то.

fxposter Jul 21 2008 at 00:23

На самом деле - еще есть вещи, коотрые бы можно было добавить, чтобы они работали автоматически:
- Возможность сразу fetch'ить данные из нескольких таблиц
Написано-же...

fxposter Jul 21 2008 at 00:24

Получить такие данные вполне можно - через саму базу данных (а точнее - через драйвер к ней), но засовывать эти данные по обьектам таблиц прийдется вручную.

TMC Jul 21 2008 at 00:30

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

fxposter Jul 21 2008 at 00:34

Ну, это ж не ORM полноценный. Скорее - удобная обертка над бд. Нужно что-то покруче - Propel, Doctrine. :)

PS. Я могу ошибаться насчет невозможности изначальных join'ов - я в Zend_Db не спец (я больше по Symfony + Propel), но по-моему их всё-таки нет. :)

kashey Jul 21 2008 at 07:50

Эх, знакомили меня вчера с докториной
Так я и не понял зачем это.
Раскажите пожалуйста :) Удобность не упоминать, лично мне так не удобно:)

dmitry_dvp Jul 22 2008 at 13:59

А Zend_Db_Table_Select не позволяет?

fxposter Jul 22 2008 at 14:05

А ты попробуй. ;) Нет, не позволяет.

sp2k6 Jul 21 2008 at 11:09

Получаете у таблицы адаптер, у него берете селект и у селекта есть необходимые методы.
Вот пример:
$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.

fxposter Jul 21 2008 at 21:59

угу. А в итоге я не получу ни Zend_Db_Table_Row, ни Zend_Db_Table_Rowset, о чем мы и говорили.

sp2k6 Jul 22 2008 at 14:00

В последних версиях 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 :)

fxposter Jul 22 2008 at 14:06

Ок. А что оно будет делать с related_tables? :)

sp2k6 Jul 22 2008 at 14:36

А ничего:) Просто в возвращаемом объекте строки будут дополнительные поля из related_tables )

fxposter Jul 22 2008 at 14:39

Я извиняюсь, но это абсолютно не то, о чем я говорю. И "такое" мне явно не нужно.

sp2k6 Jul 22 2008 at 15:08

Я извиняюсь, значит я вас не так понял :)

silverwind Jul 21 2008 at 22:07

Все понятно, и даже то, что "разобрать результат по объектам" тоже, но выглядит много сложнее простого plain-select'а.

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

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

p.s. Еще конечно перечитаю что там с Zend_Db_Table, возможно поменяю мнение...

fxposter Jul 21 2008 at 22:23

Почитай про Doctrine, поймешь, о чем я.

silverwind Jul 23 2008 at 00:22

Хорошо.

megahertz Jul 21 2008 at 08:18

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

junk Jul 21 2008 at 08:55

Использую Zend_Db_Table в своем текущем проекте. Инструмент достаточно хороший, но имеет кучу недостатков:

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

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

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

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

UFO landed and left these words here

rbatoon89 Jul 21 2008 at 15:54

Да, Вы правы, именно из-за этого он так и ругается ))

junk Jul 21 2008 at 22:14

не совсем так, точный код не приведу но суть примерно такая:



$select = Table_A->select()

    ->joinLeft('b', 'b.id = A.b', array())

    ->where('b.x = ?', y);

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

Если интересно могу посмотреть конкретный запрос где это происходит.

Silverstorm Jul 21 2008 at 09:05

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

junk Jul 21 2008 at 22:18

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

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

fxposter Jul 21 2008 at 22:22

Ну так не используйте его как фреймворк. :)

Я вот, например, Symfony использую.

junk Jul 21 2008 at 22:29

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

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

Надеюсь с выходом шестой версии PHP 6 станет лучше и избавится от исторического мусора.

fxposter Jul 21 2008 at 22:44

Да я как бы ни против руби, ни против питона ничего не имею. :)

UFO landed and left these words here

mx2000 Jul 21 2008 at 09:58

Да PHP вообще шлак, а Zend Framework никогда бы не был написан, не появись в свое время RoR.

mx2000 Jul 21 2008 at 13:17

Судя по минусам, вижу, что кто-то готов опровергнуть мое утверждение?

mx2000 Jul 22 2008 at 03:03

Вообщем так, мелкие тупоголовые пидорасы, меня основательно заебало ваше тупорылое молчание. Поэтому слушайте внимательно, черви. Если вы не в состоянии осознать каличность такого недоязыка как PHP, то мне вас искренне жаль. PHP - это тупиковая ветвь, которая едва ли когда-нибудь догонит тот же Javascript по элегантности: слишком много косяков было допущено в 3-й версии PHP, и они до сих пор дают о себе знать. Если вы до сих пор не смогли ощутить ущербность языка и кривость реализации, значит вы вообще нихрена не шарите в программировании.

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

ЗЫ. Хабр превратился в клуб малолетних неадекватов, кричащих "супер-супер! дайте еще!". Здесь практически не осталось вменяемых перцев, за исключением, пожалуй, khim'а. И даже наступая в говно, вы будете успокаивать себя, что это вовсе не говно, а такой гламурный шоколад и вообще все идет пучком. ага.

Rando Jul 21 2008 at 10:34

Вот не надо, документация в Zend Framework сделана на отлично и навигация очень удобная и очень фрагментированая. Для каждой главы, десятки подразделов. Да и API отлично описано.

mx2000 Jul 21 2008 at 13:07

Вы не поняли мою мысль. Да, возможно ZF докрутили до состояния вменяемости. Но волшебный пеньдель зендовцам под зад (и еще кое-кому) дали разработчики Ruby On Rails. Не появись RoR - не было бы и ZF.

fxposter Jul 21 2008 at 22:00

RoR не единственный фреймворк. И не первый. ;)

mx2000 Jul 22 2008 at 02:38

Не единственный, но если прокрутить историю PHP на пару-тройку лет назад, что мы увидим? :)

voidus Jul 21 2008 at 10:24

... и вновь хочется сказать: "ты просто ищешь Django, %username%"

crocodile2u Jul 21 2008 at 10:51

ZF, конечно, тяжеловесный. Лично я в последнее время остановился на следующем варианте: примитивный ActiveRecord + QueryObject (а-я RoR, работает только под PHP-5.3+, благо проект позволяет использовать новейшие версии языка с их возможностями). Но! Если мне нужен более-менее сложный запрос - я пишу его ручками, не доверяя никаким конструкторам запросов. QueryObject же использую в сложных запросах только в том случае, если необходимо динамическое формирование различных фильтров в зависимости от запроса пользователя (QueryObject в данном случае гораздо удобнее, чем непосредственно конструировать каждый такой запрос). В моем случае я обошелся всего 2мя базовыми классами ActiveRecord & Query, не делал никаких абстракций от БД (вполне достаточно PDO с его массой возможностей). Если кому-то интересно, могу дать ссылку на СВН-репозиторий, проект доступен в открытых источниках.

Yeah Jul 21 2008 at 11:48

Интересно. Давай.

crocodile2u Jul 21 2008 at 11:59

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. Если кого действительно заинтересует все это добро - помогу разобраться, можно выйти на связь по аське или почте.

fxposter Jul 21 2008 at 12:35

Я бы сейчас не стал использовать PHP 5.3 в продакшене. А если не использовать LSB оттуда - прийдется вводить абстракцию таблицы для того, чтобы это всё нормально работало с полиморфизмом и наследованием. :)

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

Что в итоге в кодах исходного AR превращается в ужас в саппорте. Именно поэтому удобно это всё вынести в класс таблицы.

crocodile2u Jul 21 2008 at 13:04

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

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

nekufa Jul 21 2008 at 12:40

Спасибо, жаль что не понятно сколько ждать релиза пхп версии 5.3 :)
А так вообще классно всё!

kost_bebix Jul 21 2008 at 14:16

Ай яй яй :-) Сделали бы, к примеру, inaf - было бы "inaf is not framework" :-) Ъ

va1en0k Jul 22 2008 at 03:10

зф классная штука. но зенд_тейбл жутковат
чтобы использовать, стоит как минимум прописать кеширование метаинформации о таблице (благо, это в пару строк делается), иначе он каждый раз запрашивать будет при создании обьекта

кстати, как раз думал написать что-нибудь про зф: например, как я с его помощью сегодня поднял опенид-сервер на моем проекте (там не очень вышло сделать, как в скудных примерах из доков). но ломает как-то :)