Закончен новый модуль базы данных для PHPixie

[@SamDark]

Интересный подход к синтаксису. Жаль or и and без подчёркивания использовать не получится. Путаница неизбежна. Даже в примерах автор путается и пишет без подчёркивания.

[@jigpuzzled]

Кстати помнится был RFC чтобы научить позволить использовать зарезервированные слова в именах методов, но он так и не прошел. Обидно…
Лично я как выходец из С, все что начинается с нижней риски считаю чем-то что трогать не нужно, но в данном случае больше ничего не придумать.

[@xiWera]

ну можно было бы использовать для именования функций похожие по смыслу слова:
or -> whether, else, either
или сокращения:
and -> nd
:)

[@SamDark]

Ага, whatever :)

[@jigpuzzled]

вот сокращения Это точно неинтуитивно. Представьте вам попался код с такими методами, вы без документации ничего не поймете. Насчет синонимов, то во-первых я знаю много людей которые whether напишут weather 1 раз из 10-ти, а вот слово either грамматически чато идет после предыдущего «or», и тем у кого английский родной будет очень непривычно так писать. Else — это вообще никуда не подойдет, кстати тоже зарезервированное слово.

[@SamDark]

Ну и всякое по мелочи: хардкод SET NAMES utf8 и отсутствие экранирования таблиц.

[@jigpuzzled]

«set names utf8» — это в духе того что в классе Request хардкод Content-Encoding UTF8. С другой стороны мир был бы гораздо проще если бы все перешло на ЮТФ еще несколько лет назад. Вспоминаю как где-то в 2009м приходилось по многим сайтам выбирать кодировку вручную так они и cp1251 и KOI8-R ставили, при чем сайт сам был на УТФ как потом оказывалось =)

А вот таблицы екранируються, есть пример прям в тесте парсера:
github.com/dracony/PHPixie-DB/blob/3.0/tests/db/DB/Driver/PDO/Mysql/MysqlParserTest.php

[@jigpuzzled]

Кстати а что нас ждеть с базами в Yii 2.0? А то здесь что-то о ней особо никто не писал еще. Интересно все-таки =)

[@SamDark]

Документация ещё не до конца готова, но вот:

github.com/yiisoft/yii2/blob/master/docs/guide/database-basics.md — это про построение запросов и нижний уровень.

github.com/yiisoft/yii2/blob/master/docs/guide/active-record.md — это про AR.

Кроме уже описанных штук для SQL недавно сделали бэкенды для Elasticsearch, Sphinx, Redis, MongoDB. Работает как на уровне запросов, так и ActiveRecord.

[@kibizoidus]

И все-таки, зачем вы переизобрели велосипед с квадратными колесами?
Все эти ORM, API, мегатонны модных слов и продвинутых терминов…
Все это просто не работает.

[@Grox]

ORM отлично работает, очень удобно. API… вы знаете, что это такое вообще?

[@kibizoidus]

Удобно до тех пор, пока сутра тебе не приходит смс от Nagios'а, в котором ты видишь LA 60 на 4-хпроцовой машине с SSD и не можешь понять ни один запрос к базе. А при попытках что-то исправить твой ORM предусмотрительно отбивает тебе руки. Вот до этих пор — удобно! А после сидишь и шерсть на пятой точке рвешь от осознания собственной беспомощности и расплаты за удобство, когда твои клиенты, твой хлеб, твои деньги просто уходят только потому что тебе когда-то было удобно.

[@jigpuzzled]

ну тогда яя Вас сразу порадую, что даже тот ОРМ какой там сегодня позволяет очень легко и посмотреть и руками изменить любой запрос без магий за считанные секунды =)

[@liaren]

Кто-нибудь, объясните пожалуйста дураку, почему разработчики фреймворков так любят изобретать собственные ORM с привязкой к их фреймворкам? Почему нельзя реализовать ORM как standalone пакет, как Doctrine например?

[@ImLiar]

у всякого программиста есть свой синдром NIH

[@liaren]

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

[@jigpuzzled]

Ну вот тут же написано что можно буднт использовать повсюду.
А ответ на ваш вопро,- потому что любой фрейиворк силбно зависит от ОРМа и если использовать либу извне то что поьом делать если в нее например со времннем нельзя будет добавить какую-то фичу без правки кода самой библиотееи и тд

[@liaren]

А ответ на ваш вопро,- потому что любой фрейиворк силбно зависит от ОРМ

Никогда прежде не слышал ничего подобного в отношении фреймворков, только в отношении CMS или CMF. Мне кажется в идеале фреймворк должен предоставлять интерфейсы абстрагирования взаимодействия модулей с ORM таким образом, чтобы к нему можно было прикрутить любую ORM просто реализовав необходимые интерфейсы-адаптеры.

[@jigpuzzled]

Это конечно да, но я думаю что кгда кто-то начинает писать фреймворк у него есть четкие цели которые он хочет сделать по другому, в ином случае нет никакого смысла писать его в принципе. Например тут имеем другой синтаксис доступа к БД с дополнительными фичами которых раньше не было ( пермутация логических запросов в Монго).

[@Dimusik]

Мне кажется, что если фреймворк заточен под конкретную ORM, то этот фреймворк как минимум не заслуживает внимания

[@jigpuzzled]

Если даже взять симфони где можно приерутить другие ОРМ, например Пропел, то все равно получается что все модули (например Форма) просят свой адаптер е нему. То есть уж так сильно абстрагироватся не пооучится. А если нелтзя абстрагироватся то лучше уж чтоб все писали под один и тот же.

То есть ваша идея прикольная но в практике не видал такого