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

Дождались ебилдов... :)))

А давайте о каждой полу-версии каждой наколенной поделки новости постить, вот ведь клево-то будет ! 1000 новостей в день, такого ни одно новостное агенство не потянет, только ЛОР. Вася Пупкин из Бобруйска дописал 3 строчки к своей cms на пыхпыхе, ура, все человечество ликует!!!

http://onphp.org/doxy/d1/d36/classSelectQuery.html Аффтар, посмотри на hibernate и убей сибя ап стену

При первом беглом просмотре текста новости не заметил слово: "исправлено". В результате получилось: "В новой версии множество ошибок и недоработок по сравнению с предыдущей."

оо это самообман, будущее за рекурсивными компиляторами

Ну вы блин даете. Выб еще каждый написанный класс для PHP в новости писали.

Дожили... Еще и Ebuild зашибись.

ЛОР традиционно радует своими экспертами. Ни одна моська не удосужилась ознакомиться с сабжем, а по тявкам судя они это чуть ли не сами писали.

> Аффтар, посмотри на hibernate и убей сибя ап стену

Посмотри на Dlinq и тоже убей себя

www.rubyonrails.com

Честно говоря после http://www.rubyonrails.com/ - (oop open-source web framework ruby-on-rails не впечатляет... Ну и Django поприятнее будет...

>ЛОР традиционно радует своими экспертами. Ни одна моська не удосужилась ознакомиться с сабжем, а по тявкам судя они это чуть ли не сами писали.

Строго говоря, обсуждать тут нечего. Достаточно посмотреть на художетсво типа этого (http://onphp.org/examples/Forum.html), чтобы понять, что авторы заигрались в ООП до невозможности.

return $query-> set('id', $message->getId())-> set('name', $message->getName()) -> set('content', $message->getContent())-> set('forum_id', $message->getForumId())-> set('person_id', $message->getPerson()->getId())-> set('parent_id', $message->getParentId())-> set('thread_id', $message->getThreadId())-> set('created', $message->getCreated()->toString());

Это, безусловно, ОЧЕНЬ повышает читаемость программы.

Непонятно, зачем надо было городить классы SelectQuery; InsertQuery; UpdateQuery; DeleteQuery; Какой смысл __динамически__ конструировать запрос порсредством методов а-ля from() -> orderBy() -> desc ... groupBy ... limit

Вы, простите, хотите сделать АРХИпереносимый API? Поздравляю, но какой ценой? Каково быстродействие полученного кода? Какова читаемость? Сложность поддержки?

При всем перечисленном есть сомнения на счет того, что любой SQL запрос можно описать перечисленными классами. Я не увидел (может, не там смотрел?) функций манипуляции с датами/временем и прочими database-specific вещами.

Извините, Вы и для MySQL будете делать fake-таблицу DUAL, чтобы все работало единообразно с Oracle?

Зачем надо было делать все НАСТОЛЬКО сложно? Вы хотели поразить публику ООП стилем?

P.S. Непонятна направленность этого ПО: для сложных высокопосещаемых проектов все будет работать слишком медленно с пожиранием огромного количества ресурсов (да-да, я про тот проект, который писали в офисе на Дровяном переулке).

В то же время, для простых наколенных сайтов такое решение не подходит из-за слишком высокой сложности разработки.

http://onphp.org/examples/OSQL.html

Самое забавное, что подобная функциональность реализует
Стандарт SQL, но не реализует защиты от ошибочно введенных данных

echo
    OSQL::select()->from('employer')->
    get('id')->get('name')->get('birth_date')->
    where(
        Expression::between(
            'birth_date',
            DBValue::create(1980),
            SQLFunction::create('now')
        )
    )->
        toString(
            DBFactory::getDefaultInstance()->getDialect()
        );

Кому непонятно, разжевываю:
Не производится никаких проверок в методе
DBValue::create($value), а значит, можно передать не только число
DBValue::create(1980), а и строку
DBValue::create('abc xyz ijk').
Да, делается quoteValue, но это не есть защита.
Защита - это указание __типа__ принимаемых или передаваемых данных. 
И если ее нет, то увы, рано или поздно это аукнется через SQL-injection.

Далее, в API напрочь отсутствует интерфейс для value binding

Это когда делается примерно следующее:
$sql =' INSERT INTO abc (x,y) VALUES(:x,:y)';
prepare();

bind(x,1); bind(y,2);
execute()

bind(x,3); bind(y,4);
execute()

Забавно то, что для реализации binding надо всего-то передать текст запроса,
но .... сделать это нельзя, во-первых, потому, что теряется смысл во всех
нагромождениях из from ... join .... order ... group, а во-вторых, API не позволяет
связывать данные в запросе.


Короче: проект еще очень и очень сырой. Написан слишком сложно и неудобно.
Многие нужные вещи (sql-binding, шаблоны) отсутствуют напрочь.

Защита переменных, передаваемых в SQL-query, реализована недостаточно.

P.S. Во многих СУБД нет такого понятия, как LIMIT и OFFSET, тем не менее в коде есть строки
http://svn.shadanakar.org/filedetails.php?repname=onPHP&path=%2Ftrunk%2Fcore
%2FOSQL%2FSelectQuery.class.php&rev=0&sc=0

if ($this->limit)
    $query .= " LIMIT {$this->limit}";
            
if ($this->offset)
    $query .= " OFFSET {$this->offset}";

Более того, переменные $this->limit и $this->offset не эскейпятся,
что чревато SQL Injection.

Недоязячок Пых-Пых вообще не годится ни для каких проектов, кроме как "Hello, World!".

Ознакомились. Вынесли вердикт - отстой!

> Ознакомились. Вынесли вердикт - отстой!
анонимусы уже вынесли вердикт, а ты?

>Недоязячок Пых-Пых вообще не годится ни для каких проектов, кроме как "Hello, World!".

Тут дело не в языке/недоязыке, а в том, что была попытка написания удобного, универсального и безопасного API, которое не является ни универсальным, ни безопасным ни удобным.

ну ладно бы один раз новость про ЭТО запостили.. но тут уже она ПОСТОЯННО лезет!! достало.

IMHO, в язычке тоже проблема, ананизмус прав. Я как-то смотрел аналог Struts для PHP. Это было чудовищно! Ну не можно в "запор" мотор от "мерина" поставить.

Так и здесь. Недоучившиеся студенты, которые сбегали с лекций по алгоритмическим языкам и технологии программировани, потому как "учиться некогда, работать надо, веб-сайты в 'Пупкин-телеком' поддерживать", не могут даже понять ООП, не говоря о АОП и ФП. Вот и получаются уродства на Пых-Пых.

Проект без грамотных, хорошо проверенных временем MVC типа Struts (для legacy)/JFC и ORM типа Hibernate/iBatis/EEJB/TopLink/JDO, - убыток.

s/JFC/JSF , т.е. JavaServer Faces хотел сказать. Хотя MVC присутствует и в JFC/Swing.

спам прямо какой-то.. или флуд.

Критиковать PHP-шников неполиткорректно. Они и так ущербные, им и так жить тяжело, а тут ещё издеваются всякие <censored>. Народ, вы бы ещё блин пришли в ближайший интернат для У/О и начали бы их передразнивать да рожи им корчить...

Автор, по хорошему тебя бы расстрелять надо без суда и следствия. Но путь любого программиста тернист и извилист, надеюсь ты просто заблудился. Отвлекись от своего onPHP, почитай книги, например "Практику программирования" от Пайка и "Искусство программирования для UNIX" Реймонда. Это для начала, если не вдохновит - поищи еще такие же книги, их много. Если тебя так привлекает ООП везде где попало, то посмотри на внимательно на Python, Java. Посмотри как там дело с ООП, потом вернись к PHP, открой свой onPHP и помедитируй. Я верю, рано или поздно тебя посетит озарение, и ты поймешь что прелесть программ вовсе не в мешанине технологий и подходов, не в сложности, а в простоте и прозрачности. Пис.

>return $query-> set('id', $message->getId())-> set('name', >$message->getName()) -> set('content', $message->getContent())-> >set('forum_id', $message->getForumId())-> set('person_id', >$message->getPerson()->getId())-> set('parent_id', >$message->getParentId())-> set('thread_id', >$message->getThreadId())-> >set('created', >$message->getCreated()->toString()); >Это, безусловно, ОЧЕНЬ повышает читаемость программы.

Повышает, если не писать все в одну строчку....Вы ж то все поняли, не так ли?

>Вы, простите, хотите сделать АРХИпереносимый API? Поздравляю, но какой ценой? Каково быстродействие полученного кода? Какова читаемость? Сложность поддержки?

Есть потери в скорости, но железо нынче - дешевo!. + Если есть JIT компилятор, то все не так и страшно.

Каким способом бы Вы поддерживали 3(или больше) БД, скажем вашей Апп? Держали бы 3(или больше) файла с СКюЭль? И это было бы проще? У Вас свой вариант?

Сложность поддержки минимальна, так как зависимость сведена к соответствующему "драйверу" БД.

>Извините, Вы и для MySQL будете делать fake-таблицу DUAL, чтобы все >работало единообразно с Oracle?

Нет. Дело в том что АПИ представляеть вполне определенный функционал, ограничивая(до некоторой степени) возможности той или иной БД, и сводя их к "общему знаменателю". Поэтому если какая то функционаьлность внесена в АПИ которая требует таблицы ДУАЛ, для Оракл, то это означает что в мускл такая же функциональность __доступна__(может и сэмулирована с помощю фейк таблицы). То же самое касается и других, поддерживаемых, БД.

Данный АПИ может понадобится Вам только в случае если Вы используете общие возможности БД. Например если Вы используете хранимые процедуры(ХП) то Вам прийдется писать __нединамический__ скл...и то до тех времен, пока парни не внесут поддержку ХП в АПИ :)

Не экономте на железе - и все будет ОК!

PS: ОО не панацея - а способ мышления ;)

gmarik.эт.gmail.com

Открой для себя Hibernate. И ОО это не способ мышления, это способ изображать с умным видом бурную деятельность. Мышление - это логика, анализ и синтез, а ОО - это галимые структурные иерархии.

>Повышает, если не писать все в одну строчку....Вы ж то все поняли, не так ли? 

Я __заставил__ себя понять. В реальности же код был бы переписан, а автор - послан
читать книжки по основам ООП.

Это же надо - возвращать из метода класса ссылку на самого себя
и потом вызвать тот же метод класса!

Запись
$a -> setValue1(1);
$a -> setValue2(2);
$a -> setValue3(3);
$a -> setValue4(4);

ГОРАЗДО понятнее записи
$a -> setValue1(1) -> setValue2(2) -> setValue3(3) -> setValue4(4);
Потому, что в первой записи явно говорится "вызвать метод setValueX объекта $a"
и так - четыре раза, а во втором - "вызвать метод setValue4 объекта,
который возвращается методом setValue3 объекта,
который возвращается методом setValue2 объекта, 
который возвращается методом setValue1 объекта $a".

Замечу, что додуматься, не анализируя код, что метод объекта всего лишь возврашает
объект самого себя, довольно сложно; более того, такое поведение не типично.

>Есть потери в скорости, но железо нынче - дешевo!.

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

>Каким способом бы Вы поддерживали 3(или больше) БД, скажем вашей Апп?
>Держали бы 3(или больше) файла с СКюЭль? И это было бы проще? У Вас свой вариант? 

Написал уровень абстракции для __производимых_действий__,
в случае, если эти действия нетривиальны.
DB.CountAllPayments(....)

Или использовал (о ужас!) интерфейс навроде следующего:
SQL.Query("SELECT a, b, c FROM xyz WHERE a < :a AND b > :a");
с набором запросов, специфичных для конкретной СУБД.

PreparedQuery PQ = DB.Prepare(SQL.GetQuery);
PQ.BindInteger(":a", 1235);
PQ.BindFloat(":b", 1235.23);

Если язык позволяет перегружать методы, использовал
бы ровно один перегруженный метод:
PQ.Bind(":a", 1235);
PQ.Bind(":b", 1235.23);

PQ.Execute();


Это, по крайней мере, __БЕЗОПАСНО__ и есть КОНТРОЛЬ ТИПОВ.
Поймите, нет никакой необходимости делать обертку вокруг "SELECT",
"WHERE", "JOIN" итд. По той только причине, что эта часть SQL
как раз максимально стандартизирована. А вот частные реализации
функций - нет. См. ниже.

>Сложность поддержки минимальна, так как зависимость
>сведена к соответствующему "драйверу" БД. 

Ничего подобного.
Сравните:
SELECT TO_CHAR(CURRENT_TIMESTAMP, 'DD-MM-YYYY') CT FROM DUAL;
и
SELECT DATE_FORMAT(CURRENT_TIMESTAMP, '%d-%m-%Y');
Результат у запросов один и тот же, но синтаксис - РАЗНЫЙ.

Чтобы доступ был единообразным, надо делать абстрактный интерфейсный класс
и его частную реализацию для каждой СУБД (что неудобно и долго,
ибо подобных функций - море). Или вовсе не использовать такой
тип данных (что безумие).

И это - только единичный пример.

>Данный АПИ может понадобится Вам только в случае если Вы
>используете общие возможности БД. Например если Вы используете
>хранимые процедуры(ХП) то Вам прийдется писать __нединамический__
>скл...и то до тех времен, пока парни не внесут поддержку ХП в АПИ :) 

О чем и разговор: API неуниверсален. Половину вещей придется делать руками.

>Не экономте на железе - и все будет ОК! 

Так в том и дело, что onPHP API, призванный упростить работу, на самом деле ее усложняет.
Более того, он требует много больше ресурсов, как аппаратных, так и человеческих,
НЕ ДАВАЯ ПРИ ЭТОМ НИКАКОЙ ВЫГОДЫ с точки зрения абстрагирования от базы и API.

Более того, даже поверхностный анализ API выявляет несколько потенциальных мест, где возможно
возникновение SQL Injection. Проще говоря - API крайне небезопасно в использовании.

Теперь вопросы:

1) Какие преимущества в продемонстрированном API дают право называть его "зрелым"?
2) Зачем писать полсотни строк кода, который все равно не дает абстрагирования от базы,
если все тоже самое можно сделать в одну строку?

>ОО не панацея - а способ мышления ;) 

Никто не против ОО. Просто инструмент применять надо, ДУМАЯ.

А ОО мышление - это ОО логика, ОО анализ и ОО синтез. А "галимость" - от лукавого.

gmarik.эт.gmail.com

>А ОО мышление - это ОО логика, ОО анализ и ОО синтез. А "галимость" - от лукавого.

Это понятно, Вы на мои вопросы ответьте, а то Ваше поведение как-то на слив похоже.

> IMHO, в язычке тоже проблема

Да какая проблема в этом языке? Болтовни много, хоть бы кто по существу
сказал. Ну, пусть товарищ криво написал свой onPHP. Но есть же
неплохие реализации ORM на php. Самый известный - DB_DataObject. Что там
плохо на ваш взгляд?

>Запись $a -> setValue1(1); $a -> setValue2(2); $a -> setValue3(3); $a -> setValue4(4);

>ГОРАЗДО понятнее записи $a -> setValue1(1) -> setValue2(2) -> setValue3(3) -> setValue4(4);

Дело в том что у второй формы есть 2 приймущества: 1. Нет дублирования `$a` : легче поддерживать код. 2. Так как в setValue ничего не возвращает в 1м случае, то было сделано усовершенствование аka fluid interfaces. Опять же легче поддерживать код.

Да, согласен, может ввести в заблуждение, но это только по незнанию...

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

Так и есть. А удобчтво в том что в коде у вас нет ни строчки голого СКю&#1028;ль.

>Ничего подобного. Сравните: SELECT TO_CHAR(CURRENT_TIMESTAMP, 'DD-MM-YYYY') CT FROM DUAL; и SELECT DATE_FORMAT(CURRENT_TIMESTAMP, '%d-%m-%Y'); Результат у запросов один и тот же, но синтаксис - РАЗНЫЙ.

Если вы исползуете данный АПИ у вас вообще не будет вопростов данного рода. Это головная боль людей которые разрабатывают "драйвер" конкретной БД.

>DB.CountAllPayments(....) Извольте, какие пейментс?

>Чтобы доступ был единообразным, надо делать абстрактный интерфейсный класс и его частную реализацию для каждой СУБД (что неудобно и долго, ибо подобных функций - море)

Верно, но функций - не "море", а определенное количество. Как и говорил: "АПИ частично ограничавает функциональность",- и это самый большой недостаток.

>API неуниверсален. Универсален по сути, не универсален по приминению.

>Половину вещей придется делать руками. Согласен, там где использование АПИ - невозможено(зависит от задачи).

>Более того, даже поверхностный анализ API выявляет несколько потенциальных мест, где возможно возникновение SQL Injection. Проще говоря - API крайне небезопасно в использовании. Возможно, но тот факт что генерирование конечного СКюЭль происходить непостредственно в "драйвере" конкретной БД,- сводит усилия по устранению данной угрозы к минимуму. Уверен что проверку типов также можно производить(возможно она и производиться,не смотрел)

1) Какие преимущества в продемонстрированном API дают право называть его "зрелым"? А версия то какая? И кто говорил что уже зрелая...Наверно я чтото пропустил... 2) Зачем писать полсотни строк кода, который все равно не дает абстрагирования от базы, если все тоже самое можно сделать в одну строку? Вам так нравится писать все в 1ну строку? ;)

ЗЫ: споры бесконечны...Итак все останутся при своих мнениях, разве рак на горе свиснет...:) Удачи.

gmarik.эт.gmail.com

Блин, какие слывы...:)

Ждём-с формулировки аксиом ОО-логики, эмпирики ОО-анализа и принципов ОО-синтеза. Смеяться будем. А то гнать то всякие горазды, а как копнёшь глубже - ничего кроме дерьма в этом ОО и не находишь.

>Дело в том что у второй формы есть 2 приймущества: 1. Нет дублирования `$a` : легче поддерживать код.

Простите, Вы обкурились?
В чем сложность поддержки кода вида $a -> doSomething()

>2. Так как в setValue ничего не возвращает в 1м случае, то было
>сделано усовершенствование аka fluid interfaces. Опять же легче поддерживать код. 

Вы считаете, что это ЛЕГЧЕ? Легче выяснять, а __действительно__ ли В ЭТОТ РАЗ
метод возвращает именно ссылку на собственный объект, а не ссылку на другой объект,
например, подзапрос?

>Так и есть. А удобчтво в том что в коде у вас нет ни строчки голого СКюЄль. 

Сорок строчек кода вместо одной -- удобнее?
Ну хорошо, пусть так. Но скажите мне, какой смысл делать обертку для тех вещей, которые
не различаются в разных диалектах SQL? Для ЧЕГО надо делать обертку для
"SELECT", "FROM", "WHERE", "AND" .... ?

>Если вы исползуете данный АПИ у вас вообще не будет вопростов данного рода.
>Это головная боль людей которые разрабатывают "драйвер" конкретной БД. 

Но сейчас драйвера НЕТ. Более того, дизайн системы исключает на данный момент такую функциональность.

>Извольте, какие пейментс? 

Такие. Частная и совершенно неабстрактная с точки зрения входных данных
реализация функциональности в конкретном проекте.

Но это был только первый пример.

Вы же старательно проигнорировали второй.
Можно обработать и binding и специфические функции.

SQL.Query("SELECT a, b, c FROM xyz WHERE a > :a AND b < :b");
PreparedQuery PQ = DB.Prepare(SQL.GetQuery);
PQ.BindInteger(":a", 1235);
PQ.BindFloat(":b", 1235.23);
PQ.Execute();

>Верно, но функций - не "море", а определенное количество.

Хорошо, функций - определенное количество. Количество это довольно большое.
Писать в коде драйвер для __каждого__ диалекта SQL обертки функций - адский труд
и в большинстве случаев бессмысленный, потому, что широта применения функций ограничена.

>Как и говорил: "АПИ частично ограничавает функциональность",- и это самый большой недостаток. 

>Возможно, но тот факт что генерирование конечного СКюЭль происходить
>непостредственно в "драйвере" конкретной БД,- сводит усилия по устранению
>данной угрозы к минимуму. Уверен что проверку типов также можно
>производить(возможно она и производиться,не смотрел) 

Еще раз: _внимательно_ посмотрите исходный код. Данные, передаваемые в LIMIT/OFFSET, НЕ эскейпятся.
Никаких проверок в драйвере нет. Он исполняет то и только то, что ему сунули.

http://onphp.org/doxy/dd/d5f/MySQL_8class_8php-source.html
http://onphp.org/doxy/d1/de5/Sequenceless_8class_8php-source.html

Более того, в куче диалектов вовсе нет LIMIT/OFFSET.

>И кто говорил что уже зрелая...Наверно я чтото пропустил...

Ознакомьтесь:
http://onphp.org/
>о продукте
>onPHP &#8211; это зрелый, лицензированный под GPL, многоцелевой
>объектно-ориентированный инструментарий для языка PHP. 

>Вам так нравится писать все в 1ну строку? ;) 

Повторяю вопрос:
Если данное API НЕ ДАЕТ абстрагироваться от диалекта SQL, КАКОЙ СМЫСЛ использовать его, когда
все тоже самое можно сделать РОВНО В ОДНУ СТРОКУ - plain text query?


>Итак все останутся при своих мнениях, разве рак на горе свиснет...:) Удачи. 

Слив можно считать состоявшимся?

> return $query-> set('id', $message->getId())-> set('name', $message->getName()) -> set('content', $message->getContent())-> set('forum_id', $message->getForumId())-> set('person_id', $message->getPerson()->getId())-> set('parent_id', $message->getParentId())-> set('thread_id', $message->getThreadId())-> set('created', $message->getCreated()->toString());

> Это, безусловно, ОЧЕНЬ повышает читаемость программы.

Ты не просек фишку! На самом деле такие финты можно делать только в ПХП начиная с пятерки (в ПХП4 только с промежуточными переменными, вот такая загогулина), вот ребята и радуются...

@stellar: а вы молодец, очень грамотно все говорите. Если бы еще и в листе их выступили и/или форуме - цены бы вам не было.

>$a -> setValue1(1); $a -> setValue2(2); $a -> setValue3(3); $a -> setValue4(4);

Может скоротиться до: using ($a = new myCoolObject()) { setValue(1); setValue(2); setValue(3); setValue(4); }

И это только простой пример....

Только вот ПХП не умеет такого.

Как альтернатива тут может пройти fluent interface. http://www.martinfowler.com/bliki/FluentInterface.html На крайняк: http://c2.com/cgi/wiki?DontRepeatYourself

>Так и есть. А удобчтво в том что в коде у вас нет ни строчки голого СКю&#1028;ль.

>Сорок строчек кода вместо одной -- удобнее?

А вы с какой целью интересуетесь? (С) чтоб в даном случае поменьше кода написать? чтоб переносимый код?

>Ну хорошо, пусть так. Но скажите мне, какой смысл делать обертку для тех вещей, которые не различаются в разных диалектах SQL? Для ЧЕГО надо делать обертку для "SELECT", "FROM", "WHERE", "AND" .... ?

Тоесть Вы утверждаете что диалекты не отличаются? Смело! А как насчет, например кавычек для имен колонок? МуСКЛ: ` (обратная) ПГСКЛ: ' СклЛайт: " (Знатоки исправте/добавте если что...) И если использывать case-sensitive names то тут они обязательны. По идее СКЛ-стандарт должен бы помочь Нам в том чтоб не инкапсулировать сырой запрос. Но почемуто все совсем не по-стандарту... А как быть с другой половиной, там где точно отличается?

>Но сейчас драйвера НЕТ. Более того, дизайн системы исключает на данный момент такую функциональность.

Зделайте полезное....;)

>Извольте, какие пейментс? >Такие. Частная и совершенно неабстрактная с точки зрения входных данных реализация функциональности в конкретном проекте.

Вот именно что часная...а люди ведь не только "под себя" пишут... Некоторые и оценят. А вот гдето так бы вышлядел ОО вариант. ;) DB.GetObjects(typeof(Payment)).Count; Заметь что АПИ какраз абстрагируется от всяких пейментс. В этом его и Сила. Потомучто клепать варианты типа: DB.CountAllOrders() DB.CountAllCustomers() ....итд совсем не по приколу... и это уже совсе другой уровень приожения...

>Можно обработать и binding и специфические функции. Биндиг не затрагивал...потомучто это часный случай в целом АПИ. А про специфические функции повторятся не охота... Если Аффтар посчитал нужным "писать в коде драйвер для __каждого__ диалекта SQL обертки функций" значит аццкый труд ему по кайфу... Напишите письмо, спросите почему...Он, как никто обьяснит что к чему.

>Еще раз: _внимательно_ посмотрите исходный код. Данные, передаваемые в LIMIT/OFFSET, НЕ эскейпятся.

Ну, Вы можете направить их на путь истинный! ;) Разве так сложно добавить ескейпинг?

>Если данное API НЕ ДАЕТ абстрагироваться от диалекта SQL, КАКОЙ СМЫСЛ использовать его, когда все тоже самое можно сделать РОВНО В ОДНУ СТРОКУ - plain text query?

А пацаны то не знают...(C) А если серьезно, то Вы правы: если не дает абстрагироватся - надо делать в одну строку.

Можно узнать сколько СУБД "поддерживает" Ваше приложение? Если нет надобности...то мы с Вами беседуем о разных вещах.

>Слив можно считать состоявшимся?

Конечно. Можете наклеить очередную звезду на монитор!

ЗЫ: Спасибо, окончил.

gmarik.эт.gmail.com

Тебе уже сказали - смотри на Hibernate. Чтоб не позорицца.

>Тоесть Вы утверждаете что диалекты не отличаются?

В ряде случаев - нет. И там, где не отличаются, инкапсулирование 
бес-по-лез-но.

>Смело! А как насчет, например кавычек для имен колонок? МуСКЛ: ` (обратная) ПГСКЛ: ' СклЛайт: " (Знатоки исправте/добавте если что...) 

Да никак. Отлично без них живется.

>И если использывать case-sensitive names то тут они обязательны.

Уууууу.... Как все плохо... 

Если Вы пишете переносимый код, ЗАЧЕМ специально делать его
еще более сложным для переносимости?
Чтобы написать вот такой вот интерфейс и радоваться тому, как все стало "круто"?

Тем не менее, ничто не мешает написать
для Oracle
SELECT TO_CHAR(CURRENT_TIMESTAMP, 'DD-MM-YY') DT FROM xyz;
для PostgreSQL
SELECT TO_CHAR(CURRENT_TIMESTAMP, 'DD-MM-YY') AS DT FROM xyz;
для MySQL
SELECT DATE_FORMAT(CURRENT_TIMESTAMP, '%d-%m-%Y') DT FROM `xyz`;

Положить набор запросов во внешнюю подгружаемую .so и обращаться
к запросам  прримернор так:
SQLQuery oQuery(QueryFactory.GetQuery(QueryId));
oQuery.Prepare(....

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

>По идее СКЛ-стандарт должен бы помочь Нам в том чтоб не инкапсулировать сырой запрос. Но почемуто все совсем не по-стандарту... А как быть с другой половиной, там где точно отличается?

Ееще раз, поймите, НЕТ СМЫСЛА ИНКАПСУЛИРОВАТЬ одинаковые для
всех диалектов ключевые слова и оператоооры.
Тем не менее, это делается в onPHP.
А вот для специфичных вещей диалекта (я приводил прример с датой)
абстракция не сделана.

Это значит, что потрачена куча времени на, в, общем-то, бесполезную
работу.

>Ну, Вы можете направить их на путь истинный! ;) Разве так сложно добавить ескейпинг?

Зачем? Там главная проблема не в эскейпинге.
Там, ИМХО, весь код надо выбросить.
Повторяю: если такое тяжелое АПИ не дает возможности 
абстрагироваться от диалекта (а оно не дает), то оно (АПИ)
не нужно.

Даже беглый анализ выявляет несколько мест с потенциальной
SQL-Injection, код __очень__ требователен к ресурсам,
код плохо читаем и слишком перегружен ненужными сущностями.

>Можно узнать сколько СУБД "поддерживает" Ваше приложение? Если нет 
надобности...то мы с Вами беседуем о разных вещах.

Я не пишу на PHP. Я пишу на C++.
Поддерживаемые диалекты - Oracle / PostgreSQL / Sybase ASE.

Метод я описал выше, повторяться не считаю нужным.

> Если Вы пишете переносимый код, ЗАЧЕМ специально делать его
> еще более сложным для переносимости?

Не все проекты пишутся с нуля, иногда они уже написаны кем-то.

> Чтобы написать вот такой вот интерфейс и радоваться тому, как все стало "круто"?
> Тем не менее, ничто не мешает написать
> для Oracle
> для PostgreSQL
> для MySQL

И для всех остальных баз - точно так же? Вы это переносимостью называете?

> Это - только один изз вариантов, возможно, не самый лучший,
> но зато гораздо более удобный, а самое главное - быстрый.

"Удобный" - понятие субъективное. "Быстрый" - зависит от того с чем сравнивать. "Не самый лучший" - это точно, десятки лет назад уже были известны и тщательно описаны более грамотные подходы.

> Ееще раз, поймите, НЕТ СМЫСЛА ИНКАПСУЛИРОВАТЬ одинаковые для
> всех диалектов ключевые слова и оператоооры.
> Тем не менее, это делается в onPHP.

А кто сказал, что OSQL - это абстракция? Где это написано?

Вдумчиво смотрим хотя бы сюда - http://onphp.org/doxy/ и видим "query builder".

Разницу понимаете? Или кипящее го^W возмущение заметить не дает?

> А вот для специфичных вещей диалекта (я приводил прример с датой)
> абстракция не сделана.

Все задатки для нее существуют, сделать ее не сложно.

> Это значит, что потрачена куча времени на, в, общем-то, бесполезную
> работу.
> Зачем? Там главная проблема не в эскейпинге.
> Там, ИМХО, весь код надо выбросить.

О! А пацаны-то не знают! (С)

> Повторяю: если такое тяжелое АПИ не дает возможности
> абстрагироваться от диалекта (а оно не дает), то оно (АПИ)
> не нужно.

Тяжелое по сравнению с чем? С хибернейтом? Не курите это больше. Что оно вам не дает - тоже не ясно, вы сусликов наблюдаете там, где ими и не пахнет (см. выше про OSQL).

> Даже беглый анализ выявляет несколько мест с потенциальной
> SQL-Injection,

Напрямую указанный SelectQuery нигде не используется, судя по примерам. А кричать, допустим, что "доступ к перекомпиляции ядра - дает потенциального рута" - глупо.

> код __очень__ требователен к ресурсам,

Замеряли? Поделитесь результатами профайлинга.

> код плохо читаем и слишком перегружен ненужными сущностями.

А мне ТАТУ с Пугачёвой не нравятся.

> > Можно узнать сколько СУБД "поддерживает" Ваше приложение? Если нет
надобности...то мы с Вами беседуем о разных вещах.

> Я не пишу на PHP. Я пишу на C++.

А gmarik правильно спросил. А вы, простите, обосрались, блеснув и незнанием предмета, и обсуждением php-программы с позиций возможностей c++.

> Поддерживаемые диалекты - Oracle / PostgreSQL / Sybase ASE.

Бог в помощь держать по одному запросу для каждой БД. Когда голова отдыхает - работают ноги.

> Метод я описал выше, повторяться не считаю нужным.

Спасибо.

Извините за предыдущий пост. Сразу не заметил - http://reki.ru/massvirthosting_php.html

Все вопросы сняты.

>Не все проекты пишутся с нуля, иногда они уже написаны кем-то. 

Брррр.... Это что, в __УЖЕ_СУЩЕСТВУЮЩИЙ__ проект на PHP Вы предлагаете
вкрутить onPHP?
Уверяю, скорее всего ничего не получится. Получится переписать почти с нуля.

Или к старой базе надо кровь из носу сделать новый МЕГАинтерфейс?
А причем тут, простите, другие диалекты SQL?

Или (ужас-то какой) надо взять старый проект со старой базой и вкорячить в него
поддержку еще восьми СУБД посредством onPHP?

>И для всех остальных баз - точно так же? Вы это переносимостью называете? 

Простите, но тоже самое делается в onPHP ;) ;).
Пишется N реализаций для N диалектов.... но при этом все равно ничего не получается...
а не получается потому, что в диалектах используются РАЗНЫЕ ВСТРОЕННЫЕ ФУНКЦИИ.
Это можно обойти, написав для каждой функции абстрактную обертку, но беда в том,
что функций слишком много, упаришься это делать.

>А кто сказал, что OSQL - это абстракция? Где это написано? 
>Вдумчиво смотрим хотя бы сюда - http://onphp.org/doxy/ и видим "query builder". 
>Разницу понимаете? Или кипящее го^W возмущение заметить не дает? 

Хорошо-хорошо. Зададим вопрос иначе.
Каким инструментом onPHP можно получить __кроссдиалектный_запрос__?

>Все задатки для нее существуют, сделать ее не сложно. 

Может быть и существуют - в головах авторов.
А вот в коде - нет.

>Что оно вам не дает - тоже не ясно, вы сусликов наблюдаете там, где ими и не пахнет (см. выше про OSQL). 

Еще раз: ОНО НЕ ДАЕТ той же работы хотя бы Датой/Временем в разных диалектах.
Значит, даже такая простая вещь УЖЕ не дает права называть onPHP кроссплатформенным решением.
Я уж не говорю про CAST и использование функций приведения.


>Напрямую указанный SelectQuery нигде не используется, судя по примерам.
>А кричать, допустим, что "доступ к перекомпиляции ядра - дает потенциального рута" - глупо. 

ВНИМАТЕЛЬНО СМОТРИМ СЮДА:
http://onphp.org/examples/Forum.html

Вот код:
get(OSQL::select()->from($this->getTable(), 'sub')->

Метод select возвращает return new SelectQuery();
SelectQuery позволяет вставить "сырые" данные.
Значит, таки-да возможность SQL-Injection есть.

>Замеряли? Поделитесь результатами профайлинга. 

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

И уж тем более - при использовании PHP. Вы сишное Zend-API видели?
Если видели, наверное знаете, как там передаются переменные в функции.

А если Вы - разработчик onPHP и хотите доказать обратное - приведите бенчмарки.

>> код плохо читаем и слишком перегружен ненужными сущностями. 
>А мне ТАТУ с Пугачёвой не нравятся. 

По делу возразить нечего?

>А gmarik правильно спросил. А вы, простите, обосрались,
>блеснув и незнанием предмета, и обсуждением php-программы с позиций возможностей c++. 

Поконкретнее, пожалуйста. Кде именно?

>Бог в помощь держать по одному запросу для каждой БД. Когда голова отдыхает - работают ноги. 

Заметно. Когда вместо одной строчки надо написать сорок и (о ЧУДО!!!) оно все равно не работает
ввиду неполной абстракции от диалекта СУБД.

ezPDO рулит

> Брррр.... Это что, в __УЖЕ_СУЩЕСТВУЮЩИЙ__ проект на PHP Вы предлагаете
> вкрутить onPHP?
> Уверяю, скорее всего ничего не получится. Получится переписать почти с нуля.

Откуда такая уверенность? Пробовали, не получилось и обиделись на весь мир?

> Или к старой базе надо кровь из носу сделать новый МЕГАинтерфейс?
> А причем тут, простите, другие диалекты SQL?
> Или (ужас-то какой) надо взять старый проект со старой базой и вкорячить в него
> поддержку еще восьми СУБД посредством onPHP?

Прекратите курить перед постами.

> Простите, но тоже самое делается в onPHP ;) ;).
> Пишется N реализаций для N диалектов....

...А не N запросов для N диалектов, как вы предлагали выше.

> Это можно обойти, написав для каждой функции абстрактную обертку, но беда в том,
> что функций слишком много, упаришься это делать.

Вы это открытие и им, и хибернейтовцам сообщите.

> Хорошо-хорошо. Зададим вопрос иначе.
> Каким инструментом onPHP можно получить __кроссдиалектный_запрос__?

Хрен его знает.

> > Все задатки для нее существуют, сделать ее не сложно.
> Может быть и существуют - в головах авторов.
> А вот в коде - нет.

Можетбыть появится скоро, может быть нет.

> Еще раз: ОНО НЕ ДАЕТ той же работы хотя бы Датой/Временем в разных диалектах.

См. выше.

> Значит, даже такая простая вещь УЖЕ не дает права называть onPHP кроссплатформенным решением.

Опять см. выше.

> Я уж не говорю про CAST и использование функций приведения.

См. выше и см. тут - http://svn.shadanakar.org/filedetails.php?repname=onPHP&path=%2Ftrunk%2Fc...

> ВНИМАТЕЛЬНО СМОТРИМ СЮДА:
> http://onphp.org/examples/Forum.html

> Вот код:
> get(OSQL::select()->from($this->getTable(), 'sub')->

> Метод select возвращает return new SelectQuery();
> SelectQuery позволяет вставить "сырые" данные.
> Значит, таки-да возможность SQL-Injection есть.

Если сам программист туда вставит СКЛ-Инжекшен - есть. А теперь смотрим еще внимательней туда же:

add(
Primitive::boolean('post')
)->
add(
Primitive::integer('forumId')->required()
)->
add(
Primitive::integer('page')->setDefault(1)
)->
......и далее

Вы как собрались инжекшен делать?

> Я - не разработчик PHP. Но у меня есть опыт разработки приложений,
> из которого следует, что вызов одной функции происходит быстрее, чем
> вызов нескольких сотен.

А 2 + 2 = 4, правильно? Прогуглитесь на тему хибернейта VS. JDBC. И такие споры тоже были. И ваши потенциальные сторонники доказывали, что JDBC это круто и быстрее, а хибернейт умрет. А он вот жив, падлюка.

> И уж тем более - при использовании PHP. Вы сишное Zend-API видели?
> Если видели, наверное знаете, как там передаются переменные в функции.

> А если Вы - разработчик onPHP и хотите доказать обратное - приведите бенчмарки.

Увы и ах.

>>> код плохо читаем и слишком перегружен ненужными сущностями.
>>А мне ТАТУ с Пугачёвой не нравятся.
>По делу возразить нечего?

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

>>А gmarik правильно спросил. А вы, простите, обосрались,
>>блеснув и незнанием предмета, и обсуждением php-программы с позиций возможностей c++.
>Поконкретнее, пожалуйста. Кде именно?

Судя по вашему подходу к разработке кросс-БД програм у вас нет даже представления о том что это все давно изобретено и сделано лучше. Вся ваша критика сводится к особенностям ОДНОГО (!!!) класса из всего проекта, который не делает то, чего делать не должен. Детский сад.
Замечания про инжекшены тоже смешны если даже поверхностно в них разобратся.

>>Бог в помощь держать по одному запросу для каждой БД. Когда голова отдыхает - работают ноги.
>Заметно. Когда вместо одной строчки надо написать сорок и (о ЧУДО!!!) оно все равно не работает
>ввиду неполной абстракции от диалекта СУБД.

Вас так это расстраивает - возьмите и допишите, а не трепитесь языком. И зачем вам дался пхп, когда ыв на нем не пишете?

A че поиск по &#1030;Д запроса в вашем файле запроса - величина постоянная? Или в конце концов Вам прийдется написать "БД, с запросами для запросов к БД"?

Да и не всегда подойдет 1 запрос.

gmarik.эт.gmail.com

>...А не N запросов для N диалектов, как вы предлагали выше. 

Почему обязательно N? Только те _ЧАСТИ_ запросов, которые отличаются.

>Хрен его знает. 

То есть, неизвестно?

>> Я уж не говорю про CAST и использование функций приведения. 
>См. выше и см. тут - http://svn.shadanakar.org/filedetails.php?repname=onPHP&path=%2Ftrunk%2Fc...
 

И что, в этот милый класс мы воткнем ВСЕ типы данных, которые встречаются ВО ВСЕХ диалектах?
А тогда для чего нужны "драйверы", если все равно есть класс, который, якобы "общий" для всех
реализаций?
А что будет с User-defined Datatypes? Это когда я в базе сам создаю свой тип данных.

>Вы как собрались инжекшен делать? 

Повторяю: класс не эскейпит __некоторые__ поля. Формально это означает что есть
ненулевая вероятность просачивания неправильных данных. Хотя бы - через пропихивание
двоичного нуля и прочей радости (если Вы не знаете, я могу рассказать, что в тот же Оракл
передаются не NULL-terminated строки, а пары "указатель-длина").

Кстати, LIMIT/OFFSET есть не во всех диалектах, зато мило живут в классе запроса.

>Судя по вашему подходу к разработке кросс-БД програм у вас нет даже представления
>о том что это все давно изобретено и сделано лучше.

Есть, есть у меня представление. Успокойтесь.

>Вся ваша критика сводится к особенностям ОДНОГО (!!!) класса из всего проекта,
>который не делает то, чего делать не должен. Детский сад. 

Это - всего лишь пример. Уверен, что ляпсусов, недоделок и кривизны полно и
в других классах. Не получается схалтурить в одном месте и сделать все хорошо в остальных.

>Замечания про инжекшены тоже смешны если даже поверхностно в них разобратся. 

Ничего, плакать захочется, когда сломают.

>Вас так это расстраивает - возьмите и допишите, а не трепитесь языком.

Повторяю: там нечего дописывать. Там надо все потереть и сделать заново, по-веловески,
а не разводить 10 классов там, 

>И зачем вам дался пхп, когда ыв на нем не пишете?

Да не нужен он мне. Мне просто непонятно, как можно такой продукт гордо называть "зрелым".

>A че поиск по ІД запроса в вашем файле запроса - величина постоянная?

А что, поиск по массиву - величина непостоянная?
Или при старте приложения нельзя сделать единожды чтение запросов?

>Да и не всегда подойдет 1 запрос. 

Еще раз: НЕОБЯЗАТЕЛЬНО ХРАНИТЬ ВЕСЬ ЗАПРОС. Достаточно только хранить специфические части
запроса. ЧТО ТОЖЕ САМОЕ как и в onPHP, только в десятки раз лаконичнее.
Не говоря уже про более другие методы.

А можно еще лучче: хранить все запросы в самом приложеннии...никакого "левого" масива не надо, загрузок при старте. Ваще Супер!

"Не говоря уже про более другие методы."

>>...А не N запросов для N диалектов, как вы предлагали выше. >Почему обязательно N? Только те _ЧАСТИ_ запросов, которые отличаются.

Ну вот и склеивайте их на здоровье.

> Повторяю: класс не эскейпит __некоторые__ поля. Формально это означает что есть > ненулевая вероятность просачивания неправильных данных. Хотя бы - через пропихивание > двоичного нуля и прочей радости (если Вы не знаете, я могу рассказать, что в тот же Оракл > передаются не NULL-terminated строки, а пары "указатель-длина"). > Ничего, плакать захочется, когда сломают.

Вам уже объяснили бредовость затеи с инжекшеном.

> Кстати, LIMIT/OFFSET есть не во всех диалектах, зато мило живут в классе запроса. > Это - всего лишь пример. Уверен, что ляпсусов, недоделок и кривизны полно и > в других классах. Не получается схалтурить в одном месте и сделать все хорошо в остальных.

Вот вам план действий: Спросите у Торвальдса, почему он столько лет халтурит выпуская глючные и недоделанные ядра. Спросите у зеркала, почему мейлрушный поиск может работать по 20 сек. и куда он жрет столько памяти. А потом вспомните чем отличаются свободные проекты от коммерческих и задумайтесь за что вы получаете деньги.

> Повторяю: там нечего дописывать. Там надо все потереть и сделать заново, по-веловески, > а не разводить 10 классов там,

По какому, простите? Опять курите?

> А что, поиск по массиву - величина непостоянная?

А головой подумать?

> Не говоря уже про более другие методы.

Можно выдыхать.

>А можно еще лучче: хранить все запросы в самом приложеннии...никакого "левого" масива не надо, загрузок при старте. Ваще Супер!

То-то они не хранятся в onPHP.
Анонимус притворяется слепым или специально не хочет видеть, что 
запрос при использовании onPHP ХРАНИТСЯ в коде приложения?

Единственное отличие - в том, что вместо одной строчки
используется несколько десятков.

Причем хранится он в НЕКРОССДИЛАЛЕКТНОМ ВИДЕ.
Более того, были приведены примеры, показываюшие что это именно так.

Повторяю:
НЕТ обертки для LIMIT/OFFSET.
В Oracle, например, нету, ну НЕТУ операторов LIMIT и OFFSET.

НЕТ обертки для функций, делающих одно и то же, но имеющих разное 
название и синтаксис в разных диалектах (TO_CHAR / DATE_FORMAT).

НЕТ приведения типов.
То, что есть - это сборная солянка, не зависящая от "драйверов".

НЕТ Prepared queries

НЕТ server-based Prepared statements

НЕТ поддержки асинхронных событий базы

НЕТ обертки для курсоров.

НЕТ работы с LOB

НЕТ возможности получения типа возвращаемого из базы объекта.

Внимание, вопрос: каковы преимущества использования onPHP, если
писать на нем выборки SQL сложнее, а кроссплатформенности как
не было, так и нет?

>Вам уже объяснили бредовость затеи с инжекшеном. 

Где именно, простите?
Были только общие слова, не подкрепленные примерами кода.

>Вот вам план действий: Спросите у Торвальдса, почему он столько лет халтурит выпуская глючные и недоделанные ядра. 

Я лично с Торвальдсом не знаком.

>Спросите у зеркала, почему мейлрушный поиск может работать по 20 сек.

И где там 20 секунд? Может, об этом лучше спросить у Вашего провайдера?

time wget 'http://go.mail.ru/search?lfilter=&num=10&q=%E2%E5%F0%F2%EE%EB%E5%F2'
real    0m0.747s
user    0m0.008s
sys     0m0.018s

>и куда он жрет столько памяти.

А Вы знаете, сколько он жрет памяти?
Может, Вы еще расскажете, на чем именно написан Поиск и какие алгоритмы там используются?

>По какому, простите? Опять курите? 

По-человессски. Это щютка, да.

>> А что, поиск по массиву - величина непостоянная? 
>А головой подумать? 

Так, по-Вашему, скорость поиска X = Y[N]; величина переменная?
Или Вам известны только ассоциативные массивы?

>А потом вспомните чем отличаются свободные проекты от коммерческих и задумайтесь за что вы получаете деньги. 

Наверное тем, что в свободных проектах можно халтурить и Вас никто с работы не погонит?

Короче, афффтор опустился до криков "сам дурак". Явный признак, когда нечего сказать.

А в Вашем случае это не ассоциатывный масив?