почему мы не падаем с ошибкой прямо на этом запросе?
Потому что там нет никакого подготовленного мульти запроса. Ни с плейсхолдерами, ни без.
Об этом много раз писали в этом треде, но вы же как тетерев на току - слышите только себя самого.
если бы мы упали, как мне объяснили на StackOverflow, это было бы отражено в результате.
как обычно, там соврали
Таким образом, проблема в том, что дефолтный режим запросов - unbuffered query
здесь абсолютно не при чём
сам не закрывает соединение
с какого перепугу-то он будет закрывать
А вместо этого мы свели вопрос к тому, что я плохо от инъекций защитил код.
Это вы и свели, начав двигать свои гениальные идеи по защите от инъекций.
За таким, что по логике Джордж Клуни может оставить отзыв о жилье только если он его бронировал, а не просто с улицы пришёл. И отзыв будет привязан к конкретной брони. Из которой уже можно получить и пользователя, и жильё. А нет брони - нет и отзыва.
Соответственно, user_id здесь избыточно, поскольку оно уже есть в таблице бронирования. Как и номер комнаты.
То есть задача именно по жилью и юзеру найти бронь, и подставить её в отзыв.
Впрочем соглашусь, что в вопросе ничего этого нет.
И забудьте про SELECT COUNT(*) + 1. Это стрельба себе в ногу на поражение. прочитайте для чего служат уникальные идентификаторы и как ими пользоваться.
INSERT INTO Reviews (rating, reservation_id) VALUES (5,
SELECT id FROM Reservations
WHERE user_id = (SELECT id FROM Users WHERE name = 'George Clooney')
AND room_id = (SELECT id FROM Rooms WHERE address = '11218, Friel Place, New York')
)
Автор не умеет писать, а вы не умеете читать. Но беретесь строчить ответы
Проблема у него при получении данных в API.
До "беру с диска" дело не доходит. Он написал это от балды, просто к слову пришлось.
Если читать вопрос предназначенными для этого органами, то это становится очевидно.
Как и многие другие доброхоты, вы выхватываете из контекста одно-два знакомых слова, и бежите строчить ответ. А надо научиться сначала понять весь вопрос целиком. И отвечать только если это у вас получилось.
JhaoDa, ему реквест распаршеный не нужен. А только сырое содержимое.
Наверняка есть способ сказать Реквесту, чтобы не парсил. Я только не знаю как
Ну или как вариант не слать application/json, а простую form-data.
Автор, вы можете поменять тип запроса с JSON на простой POST? Чтобы там была тупо пара json={...}?
Для непонятливых ещё раз: строчка json_decode($this->getContent(), true) находится в ядре ларавля.
Который очевидно парсит автоматом входящие в него данные. Для этого фреймворки и создаются.
JhaoDa, у него проблема в том, что Request автоматом заполняет входящие данные. И хочет он отключить эту функциональность, поскольку распаковка ему не нужна.
Александр Попов, мне нетрудно объяснить вам очевидные причины этой ошибки.
Но меня останавливают два момента
Во-первых, я считаю что вместо этого бессмысленного вопроса у вас есть куда более серьёзные проблемы.
Вам надо освежить память и вспомнить, что mysql_query вообще никогда не позволяла мультизапросы (были слухи что можно скомпилировать РНР с определенным ключиком, и тогда она будет позволять, но в реале этого никто никогда не видел).
Вам надо разобраться с нелепой фантазией про многопоточность в рамках одного соединения с БД.
Вам надо уяснить для себя, что защита от инъекций системы "проверенный человек вводит, мамой клянус!" - это детский лепет.
Вам надо научиться отслеживать логические нестыковки в коде
Вам надо научиться пользоваться гуглем, поскольку примеры находятся, просто надо не бросать после первого результата и уточнять поисковый запрос.
Ну или попытаться написать этот код самому - там не бином Ньютона.
И только после этого обращаться к области видимости (и зависящему от неё времени жизни) переменных.
А вторая проблема - ваше некоторое ваше зазнайство, которое постоянно проскакивает.
То окружающие не в состоянии понять ваши проблемы, то непонятное вам поведение языка - это не меньше как баг. А вариант, что причина в вашей неспособности работать с документацией вы даже не рассматриваете.
Такое отношение совсем не побуждает вам что-то объяснять.
Vitsliputsli, но PDO-то поддерживает. Так что пользователь PDO может продолжать использовать prepare.
Парсер в PDO вообще ни разу не полноценный, а простая заменялка плейсхолдеров. В том числе для обеспечения поддержки эмуляции.
Впрочем, автора вопроса все равно интересует не это.
Потому что там нет никакого подготовленного мульти запроса. Ни с плейсхолдерами, ни без.
Об этом много раз писали в этом треде, но вы же как тетерев на току - слышите только себя самого.
как обычно, там соврали
здесь абсолютно не при чём
с какого перепугу-то он будет закрывать
Это вы и свели, начав двигать свои гениальные идеи по защите от инъекций.