вот, собственно, о чём я и придирался у тебя уже два флага с непонятными названиями, а в вызывающем коде и их не будет - только непонятные труъ и фалос.
Если человек не хочет унитаз, а хочет вертолёт пусть он и берёт вертолёт, но унитаз ругать не нужно за это, он не виноват что он не вертолёт... Разницы (между mysql_unbuffered_query и mysql_query) в данном конкретном случае ноль и даже без копеек, но мне так показалось логичнее... (более веские аргументы готов выслушать)
Ты рассматриваешь вариант когда испольуешь single_query() для запроса предназначенного для rowset_query(), если этого не делать (что логично) то никакие данные не будут удалены...
Она вообще (в этом варианте) использоваться не будет (если бы класс писался для РНР5 я бы сделал её "private") запросы в класс посылаются другими 4-мя функциями (методами) Опять же если ей правильно проставлять флаги (в соответсвии с запросами) то также всё будет нормально
да какая разница? query эти флаги транслирует в fetch. ладно, пойдём с другого конца - нам нужно получить одно единственное значение - зачем выбирать всю строку?
dark-demon Кто её выбирать будет ? Класс выбирает результат запроса и не более того, а какой запрос ты пошлёшь это уже твоё дело !!! Флаги только страхуют от ситуаций чтоб один - запрос одного значения не выдал массив с массивом в котором одно значение (для удобства) - запрос массива массивов (всю таблицу) не вернул простой массив (в случае если там только один ряд) и прочие подобные ситуации
Кстати вот с этим согласен, это замечание дельное, обработка ошибок у меня всегда была "слабым" (замечу в кавычках) местом. Думаю надо добавить метод error() куда при возникновении ошибки кидался её текст... (чтоб если при вызове метода вернулся FALSE можно было её прочитать) Например так. PHP: <?php if (false === $mysql->single_query($sql)) { if (DEBUG) { // сейчас без правки этого класса // можно сделать die(mysql_error()); // но это будет стилистически не правильно // лучше добавить в класс метод error() // чтоб можно было делать так die($mysql->error()); } else { header(' тра-ля-ля 500-я ошибка'); exit(); } } ?>
Горбунов Олег Не люблю я его ! В моём понимании идеальный скрипт должен либо работать (без ошибок) либо быть в режиме отладки (выдавать ошибки), либо вываливаться без каких либо намёков на то что случилось и почему (причём последнего во время эксплуатации существовать не должно в принципе как явления, а код позволяющий так "вываливаться"должен стоять только ради приличия) и всё, другого не дано..
Vladson, и чем мешает trigger_error всему сказанному? Никаких ошибок - никаких trigger_error что можно сделать через trigger_error такого быть никогда не должно. Имхо, это уже дилетанство. Ошибки — могут быть. Необработанные ошибки — другое дело.
Заполнитель - специальный маркер в шаблоне SQL-запроса, обычно имеющий вид "?", на место которого подставляется переданное функции-врапперу значение, которое перед подставкой "обезопасивается" (замутил ппц). Типа такого: PHP: <?php $sql = $db->wrapper("INSERT INTO tbl SET pole1 = ?, pole2 = ?", "O'Reilly", " test ' test "); echo $sql; // INSERT ... pole1 = 'O\'Reilly', pole2 = ' test \' test ' ?> Подобный код упрощает работу (IMHO) и предупреждает SQL-инъекции.
ага, это когда у тебя в таблице всего 2 поля... а если десяток? начинать считать овец? лично я предпочитаю так: Код (Text): $sql= $db->prepare (' INSERT INTO tbl SET pole1 = ',"O'Reilly",', pole2 = ', " test ' test " );
нет... у меня так — PHP: $db->Query_ex('insert into table @? values @?',array_keys($data),$data); (образно, конечно, не так все буквально....)
Sergey89, конкретно инсерты и у меня так, мы говорим в общем о составлении запросов Горбунов Олег, а какая разница?
да, плюс у меня еще там спорное решение - если вместо одного аргумента передать массив, то он также будет обработан через один, но если хоть один элемент массива равен null, то весь массив выкидывается. спорное, потому, что без приведения к строке нельзя передавать непроверенные данные...