Ты что-то напутал. При наличии "вторички" соединение спокойно закрывается, без всяких ошибок. Никаких "вторых страниц" во "вторичке" быть не может. Она бывает только если ты работаешь с хранимой процедурой или выполнил мультизапрос. Я не холиварю, я хочу понять, где ты запутался..
ну вот, ты не слышал даже детскую страшилку про инъекции второго порядка, а берешься рассуждать про инъекции :) Но даже не это главное - тебя даже не смутила строгая идентичность моей аналогии. То есть, ты берешься защищаться от инъекций в стиле "здесь копать, здесь не копать". Это прямая дорога поиметь инъекцию, имей в виду.
olamedia .: я же тебе все расписал отдельным комментарием. Само по себе слово "экранировать" - неточное, бессмысленное и вредное. Оно не несет никакой конкретики, но зато имеет вполне устоявшееся неверное толкование - "добавление слешей для защиты от инъекцицй". Если кто-то хочет дать полезный ответ, то он должен в подробностях расписать - что, как и в каких случаях надо форматировать, и какие правила форматирования надо соблюдать. Иначе, если попытаться сжульничать и заменить подробное описание словом "экранировать", польза будет отрицательная. Потому что нуб поймет по-своему, и будет считать escape_string универсальной защитой от инъекций (что нам и продемонстрировал ТС).
Ахахахаха, я так и думал :) То есть, ты даже приблизительного представления не имеешь, что это за "вторичные результаты", откуда они берутся и что могут содержать :)
olamedia .: суть неверная. В статье упоминается некое несуществующее в природе "SQL экранирование" - абсолютно бессмысленная вещь, которую каждый нуб будет понимать по-своему а в итоге все сделают неправильно. То есть, ценность этого совета - отрицательная.
не стоит, все-таки, употреблять слово escape. оно такое же дурное, как и "экранирование". Ну как можно один и тем же словом обозначать и добавление слешей к кавычкам и добавление кавычек к выражению? Как бедный нуб должен понимать в итоге это слово? Во-первых, надо говорить "форматирование". А во-вторых, если проблема в tourpreregtable, то недо не толкьо добавлять апострофы, но и искейпить их. Поскольку .$nearTour['tourpreregtable'] - тут явно может быть что угодно, например, '; DROP DATABASE x;
Не важно где живет переменная $this->dbresult и откуда к ней доступ. Главное что она есть. Значит, будут и глюки. ДБАЛ ВООБЩЕ не должен персистить результаты, в принципе. Я, конечно, понимаю, что ты гений а Вез - лох, но он почему-то в ПДО сделал отдельный класс для результата. А не "приватную переменную без доступа извне".
В чем конкретно накосячили? Дело не в стоимости, дело в осмысленности. Все дополнительные результаты живут строго в пределах соединения и умирают вместе с ним. То есть отдельно их убивать смысла нет
Но ты пойми главное - что ни один твой вопрос не несет никакого смысла. Фреймворк можно любой, а можно совсем без фреймворка. Nginx не потому что он "лучше" для апи просто потому что это мейнстрим сейчас на серверах. Спрашивать о технологиях имеет смысл, если у тебя есть какие-то конкретные запросы. А на текущий твой вопрос можно ответить только то, что я написал.
Технология MVC как раз и гарантирует (при правильном применении), что формат отдаваемых данных никак не отражается на логике приложения. То есть сервис, который отдаёт JSON, с точки зрения фреймворка пишется абсолютно точно так же как сайт, который отадёт HTML.
Ну, я-то как раз вопрос читал, и ничего, кроме REST (ну или там XMLHTTPRequest) на такой вопрос ответить в принципе нельзя. Бессмысленный вопрос с бессмысленными тегами. Любой инструмент полезен только если он применяется по назначению, а не потому что чувак с тостера его использует.
