Если честно, то жесть.<div>Хранить запросы в шаблонах, ещё и использовать синтаксис шаблонизатора для генерации шаблна —вообще зло.</div><div><br></div><div>Чем вам обычный Perl не устраивает?</div><div>Генерация строки легко решается без шаблонизатора.</div>
<div><br></div><div>Но за тимтоуди спасибо)</div><div><br><br><div class="gmail_quote">2011/11/8 Ivan Petrov <span dir="ltr"><<a href="mailto:i.petro.77.00@gmail.com">i.petro.77.00@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Заспорили мы тут с некоторыми товарищами.<br>
<br>
в итоге пришло к тому "возможно или нет" написать генератор запросов.<br>
видимо правы все или неправы все. тут просто вопрос точки зрения.<br>
<br>
<br>
Я помню на одной из перл-конференций один умный человек  читал  лекцию<br>
про трансгуманизм.  Там  была  хорошая  мысль:  не  стоит  гнаться  за<br>
оптимизацией,  если  дело  можно  решить  мегафлопсами.   Они   всегда<br>
дешевле.<br>
<br>
В каких-то нишах он прав. Вероятно для этих же ниш подойдет и DBIC.<br>
<br>
Вот. Ну а для ниш, где флопсы выделенные БД таки не решают всеж-таки<br>
ваяем шаблонный движок для работы с SQL.<br>
<br>
Сперва мы тут ваяли движок с собственным шаблонным языком.<br>
<br>
Затем применяя его на практике пришли к тому что собственный язык -<br>
плохо, надо идти по пути Mojo. То есть встраиваемый перл.<br>
<br>
В итоге пришли вот к такому синтаксису.<br>
<br>
SELECT<br>
    *<br>
FROM<br>
    table<br>
WHERE<br>
    id = <%= $id %><br>
<br>
где $id - именованный параметр переданный запросу.<br>
<br>
<br>
Ну или даже так:<br>
<br>
SELECT<br>
    % if ($type eq 'count') {<br>
        COUNT(*) AS count<br>
    % } else {<br>
        *<br>
    % }<br>
FROM<br>
    table<br>
WHERE<br>
    sid = 123<br>
    % if ($filter->filter1) {<br>
        AND field1 = <%= $filter->filter1 %><br>
    % }<br>
    % if ($filter->filter2) {<br>
        AND field2 = <%= $filter->filter2 %><br>
    % }<br>
<br>
Получается более изящно и сильно более гибко, однако цена этому в<br>
примерно в полтора-два раза бОльшее время на парсинг. Впрочем для<br>
сложных SQL оно сравнимо (у старого парсера оно оосло в зависимости от<br>
сложности, тут слабо зависит).<br>
<br>
SQL-ки размещены в выделенной директории, имеют фиксированное (пока)<br>
расширение '.sql.ep' и DBI расширен тремя допметодами<br>
<br>
 - select - выборка набора данных (аналог selectall_(hash|array)ref)<br>
 - single - выборка одной строки  (аналог selectrow_hashref)<br>
 - perform - выполнение SQL-запроса (аналог do)<br>
<br>
Покамест на выходе простые итераторы, позволяющие сделать просто<br>
проход по выборке, а объекты просто предоставляют доступ к выбранным<br>
полям (AUTOLOAD). В планах сделать отложенные SQL-запросы ну и более<br>
расширить API итераторов (сейчас они частично DBIC совместимые).<br>
<br>
Если кому интересно, то модуль лежит на CPAN - DBIx::DR.<br>
<br>
Ссылки на git нет. Git - в закрытом проекте. unfortunatelly.<br>
<br>
Замечания, предложения крайне интересны :)<br>
Спорить по поводу того что некрута писать SQL-запросы руками больше не<br>
буду :)<br>
<font color="#888888"><br>
<br>
--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>С уважением,<br> Анатолий Шарифулин.<br>
</div>