Сегодня наткнулся на жесточайшую багу… У кого развернута сборка магазина или хотя бы стоит пакет shopModx, попробуйте в консоли выполнить вот такой код: <?php
print '<pre>';
$q = $this->modx->newQuery('ShopmodxProduct');
$q->command('update');
$q->set(array(
'sm_price' => 154.99,
));
if($q->prepare()){
print $q->toSQL();
} Результат: UPDATE modx_shopmodx_products SET sm_price = 154
Не 154.99, а просто 154… Думаю, каждый понимает печальность последствий, особенно когда полно товаров с ценниками типа 0.99
Но что тут самое интересное? А то, что если просто выполнить вот так, то все будет ОК: $o = $modx->getObject('ShopmodxProduct', $id);
$o->set('sm_price', 154.99);
$o->save(); Первое: такое переменчивое поведение связано с тем, что через разные методы используются различные механизмы формирования запросов. К примеру, при вызове xPDOObject::save() у нас вполне явный SQL формируется. А вот при использовании xPDOQuery::set() уже механизм другой. И здесь самая западня вот в этих строчках: elseif (!in_array($fieldMeta[$key]['phptype'], $this->_quotable)) {
$type= PDO::PARAM_INT;
} А какие типы у нас quotable?
'string', 'password', 'date', 'datetime', 'timestamp', 'time' Как видим, там нет ни double, ни float. В итоге все приводится к INT-типу, а это, как известно, не подразумевает дробные числа. При этом в PDO в принципе нет ничего типа FLOAT или типа того. В сети полно вопросов PDO::PARAM_FLOAT does not exist, why?.
В итоге, видится только один вариант — определить float и double как строковые. А там сама база данных пусть занимается вопросами конвертации, она это обязательно сделает. Отправил PR. Честно говоря, бага на столько скрытая, что я даже уже почти забил… Но в последний момент чутье вывело меня к нужной строчке. немного похвастаюсь)))
Пожалуйста. И бери на вооружение, потом что это очень мощный механизм. Правда есть баги :-)
Спасибо, разбираюсь потихоньку с getdata-процессором, а что бы понять как он работает отдельные части отрабатываю на чистых запросах через консоль.
Значит вы не все ошибки нам показали. Шлите в личку доступы в админку.
Если LogLevel(1), то просто модальное окно с сообщение «syntax error:». И все. Данные при этом не сохраняются.
DEBUG — это вообще не серьезно. Это просто отладка. Поменяйте $modx->setLogLevel(3); на $modx->setLogLevel(1); или $modx->setLogLevel(xPDO::LOG_LEVEL_ERROR); и все. Это просто информационные сообщения.
Так это и есть весь код. Процессор 'web/catalog/products/article/getdata' сделан по образу и подобию из топика про поиск по tv. Вот ответ, если поменять loglevel: print '</pre>'; Loading... syntax error: [2013-11-27 17:40:00] (DEBUG @ /manager/components/console/connectors/console.php) Language string not found: "Имя возвращающей значение функции. getBaseUrl или getBasePath" [2013-11-27 17:40:00] (DEBUG @ /manager/components/console/connectors/console.php) Language string not found: "" [2013-11-27 17:40:00] (DEBUG @ /manager/components/console/connectors/console.php) Language string not found: "id медиасурса. Обязательное" Плюс еще несколько таких же DEBUG.
Выложите полный листинг кода, в котором возникает ошибка, и полный текст ошибки.