Вот чтобы разобраться, в чем же проблема, я и предлагаю сейчас прислать данные лично мне. Страшно писать в support — отправьте их мне в личку на Хабре. Чтобы понять причины проблемы, нужно ее воспроизвести, а когда нет шагов по воспроизведению, этого очень сложно добиться.
Ваше неудобство вполне понятно: для ряда людей и правда удобнее было бы общаться с кандидатами напрямую. В скором времени мы планируем много разных нововведений в разделе Работа. Думаю, решится и эта проблема. Спасибо за Ваши комментарии.
Пришлите, пожалуйста, через feedback.yandex.ru/?from=MK&side= (с пометкой «Для Дмитрия Котерова по его просьбе»):
— Ваш старый логин (почтовый адрес) и пароль к нему
— Ваш email для связи (у нас могут возникнуть дополнительные вопросы), а еще лучше — ICQ или gtalk.
Это очень интересная тема.
А можете дать прямую ссылку на документацию по by_key-функциям?
А то я за 10 минут в Гугле не нашел внятных подробностей, как оно работает. Ссылки в основном ведут на доки по UDF-функциям MySQL. Также есть ссылки на листы рассылки, из которых следует, что by_key-функции применяются для привязки некоторого набора ключей гарантировано к одному серверу. Про тэги ни слова.
Причины две:
1) получить фидбэк от профессионального сообщества, представителей которого здесь больше, чем где-либо;
2) узнать альтернативные (возможно, более эффективные) методы реализации того, что делают предложенные библиотеки.
Каждый слот имеет список тэгов, которыми он помечен, вместе с версиями этих тэгов. При инвалидации тэга его версия изменяется, поэтому библиотека при извлечении очередного слота понимает, что он «протух». Ну а для ускорения операции используется «групповой фетч» в memcached, который поддерживается в новых версиях PHP (т.е. за один запрос к memcached получаются сразу все тэги некоторого слота).
На тот момент, когда я ее проверял (несколько месяцев назад) она сегфолтилась, а иногда висла и начинала бесконечно отжирать память. Возможно, сейчас ее уже починили. Кстати, в дистрибутиве Dklab_Cache есть Dklab_Cache_Backend_MemcachedTag, который именно для memcached-tags предназначен (адаптер для Zend_Cache_Backend).
Если глянуть в исходники библиотеки, то видно, что краевых условий и нюансов там действительно много. Например, NULL в array и hstore выглядит как NULL, в ROWTYPE — просто как пропуск значения между двух запятых. Кавычки квотятся по-разному: в array и hstore — слэшем, в ROWTYPE — удвоением. Соответствующие особенности и с квотингом слэшей и пустых строк, а также непустых строк (где-то их нужно заключать в кавычки, где-то нет).
Соответственно, данная библиотека полезна тем, кому нужно проверенное и покрытое тестами продакшен-решение, устойчивое к инъекциям и виду входных/выходных данных. Те, кто использует типы неактивно, вполне могут обходиться самодельными функциями.
А насчет синтаксиса Propel (и вообще ORM) — то на первый взгляд и правда кажется, что он очень громоздкий. Но на практике эта громоздкость, что удивительно, почти совсем не мешает. А вот много проблем с тем, что Propel (и другие ORM) способствуют неконтролируемому росту кол-ва разновидностей («планов») SQL-запросов, и оптимизировать такой код впоследствии становится очень сложным. SQL оказывается ровным слоем размазанным по всему приложению. Впрочем, та же проблема и с ручной генерацией SQL через тот же DbSimple или PDO. Локализовывать нужно SQL, ох локализовывать…
Ну там в библиотеке как бы не одна строка, а три:
— отслеживание фильтра, какие ошибки преобразовывать в исключения, а какие — нет;
— идеома «выделение ресурса есть инициализация», в результате чего преобразователь нотисов в исключение автоматом отключается при выходе из области видимости текущего блока;
— иерархия «серьезностей» ошибок.
Подозреваю, что ненависть эта связана с WSDL-схемами. Они, как тут выше правильно заметили, «подходят для энтерпрайза». Попробуйте без них, в большинстве случаев жизнь становится сильно легче. Без WSDL PHP-шный SOAP превращается в простой и приятный инструмент, да и с точки зрения ресурсов все достаточно хорошо (по сравнению с обычными издержками на выполнение PHP-кода накладные расходы на SOAP-кодирование и декодирование блекнут).
Хм. Будет знать {some/node}, но не поймет <xsl:value-of select=«some/node» />? Или узнает {if something}, но не додумается до <xsl:choose><xsl:when test=«something»>? Конечно, я понимаю, что новички разные бывают, но чтоб такое не понять, нужно очень сильно постараться…
Про 95% — мне кажется, это сильное преувеличение. Чтобы использовать XSLT в качестве веб-шаблонизатора, нужно как минимум еще применять xsl:template, xsl:call-template (или apply-templates, но это реже) и xsl:import. Без них никакого шаблонизатора не сделать, а чтобы их применять, нужно очень хорошо себе представлять, как работает xslt.
Да, но в этом случае мы теряем в производительности: придется результат XSLT-преобразования прогонять через еще одно XSLT-преобразование для замены локализованных вставок. Кроме того, для улучшения производительности иногда имеет смысл автоматически «вкомпилить» строковые значения в исходный XSLT еще до преобразования, т.е. заменить {#hello} на «Привет». Тогда не будет тратиться время на вызов функции вида h:const(). Такую замену можно сделать при помощи препроцессор Dklab_DOMDocument, на котором и написан, собственно, ShortXSLT.
Вы совершенно правы, это правда был бы бред. Именно поэтому это не «XSLT-процессор, написанный на PHP», а «система для поддержки упрощенного синтаксиса XSLT для встроенных в PHP-классов XSLTProcessor и DOMDocument». Поправил в посте, чтобы не было недопониманий.
— Ваш старый логин (почтовый адрес) и пароль к нему
— Ваш email для связи (у нас могут возникнуть дополнительные вопросы), а еще лучше — ICQ или gtalk.
Разберемся, в чем проблемы.
А можете дать прямую ссылку на документацию по by_key-функциям?
А то я за 10 минут в Гугле не нашел внятных подробностей, как оно работает. Ссылки в основном ведут на доки по UDF-функциям MySQL. Также есть ссылки на листы рассылки, из которых следует, что by_key-функции применяются для привязки некоторого набора ключей гарантировано к одному серверу. Про тэги ни слова.
1) получить фидбэк от профессионального сообщества, представителей которого здесь больше, чем где-либо;
2) узнать альтернативные (возможно, более эффективные) методы реализации того, что делают предложенные библиотеки.
Соответственно, данная библиотека полезна тем, кому нужно проверенное и покрытое тестами продакшен-решение, устойчивое к инъекциям и виду входных/выходных данных. Те, кто использует типы неактивно, вполне могут обходиться самодельными функциями.
А насчет синтаксиса Propel (и вообще ORM) — то на первый взгляд и правда кажется, что он очень громоздкий. Но на практике эта громоздкость, что удивительно, почти совсем не мешает. А вот много проблем с тем, что Propel (и другие ORM) способствуют неконтролируемому росту кол-ва разновидностей («планов») SQL-запросов, и оптимизировать такой код впоследствии становится очень сложным. SQL оказывается ровным слоем размазанным по всему приложению. Впрочем, та же проблема и с ручной генерацией SQL через тот же DbSimple или PDO. Локализовывать нужно SQL, ох локализовывать…
— отслеживание фильтра, какие ошибки преобразовывать в исключения, а какие — нет;
— идеома «выделение ресурса есть инициализация», в результате чего преобразователь нотисов в исключение автоматом отключается при выходе из области видимости текущего блока;
— иерархия «серьезностей» ошибок.
Про 95% — мне кажется, это сильное преувеличение. Чтобы использовать XSLT в качестве веб-шаблонизатора, нужно как минимум еще применять xsl:template, xsl:call-template (или apply-templates, но это реже) и xsl:import. Без них никакого шаблонизатора не сделать, а чтобы их применять, нужно очень хорошо себе представлять, как работает xslt.
Также (ИМХО) «мега-темплейты» не имеют отношения к конструкциям if-else и foreach, а имеют отношение, главным образом, к неопытности XSLT-писателя.