Как устранить ошибку Only variables can be passed by reference?

Интересно, получается, что передача по ссылке элемента массива полученного по ключу - это недокументированная возможность. Причем это не побочный эффект, php не просто создает новую переменную, а в зависимости от функции, если она требует значение или требует ссылку, будет использоваться разный код - FETCH_DIM_R или FETCH_DIM_W соответственно.
В общем, оно логично. Нет смысла передавать что-либо по ссылке, если у него нет имени и к нему никак потом не обратиться. А к элементу массива обратиться можем, а значит такое поведение нужно.
Со строкой тоже самое, но для строк запрещен FETCH_DIM_W, по понятным причинам.

Как устранить ошибку Only variables can be passed by reference?

galaxy, спасибо, вы правы, это работает.
Хотя не понимаю почему, в мануале указано, что только:
Variables, i.e. foo($a)
References returned from functions, i.e.:
можно передать по ссылке. Если есть информация почему это работает, буду благодарен.

Как исправить ошибку in_array(): Argument #2 ($haystack) must be of type array, bool given (0)?

Сделайте так, чтобы $arSelectFields была массивом. А уж как, зависит от логики вашего скрипта.

Как устранить ошибку Only variables can be passed by reference?

Денис Московский,

тут вроде по ссылкам и передаются переменные...

Тут, 3 аргумент - получение значения по индексу массива, а он просит переменную.

PHPParser::GetParamsRec($el_val, $arAllStr, $arResult[$el_ind]);

Автоматическое закрытия сделки?

0xsetup,

Из идей пока 1: сделать отдельную горутину,(срабатывает раз в час)

Отличная идея. Если же разместите логику в базе, потом могут быть проблемы, если нужно добавить функционал, который невозможно разместить в базе.

будет по LIMIT OFFSET пробегаться по всем сделкам

Не нужно. Обычный запрос с фильтрацией по статусу и нужной дате.

Автоматическое закрытия сделки?

можно просто по требованию вычислять как разницу между началом сделки и текущим временем

Не получится, это не просто значение в базе, это событие, которое вызовет действия - возврат денег и т.п.

Для чего делают таблицы public?

shurshur,

pg-специфиеская возня со схемами в запросах ни к чему.

Схема это не pg-специфика, они присутствуют во многих СУБД. То, что в MySQL не удосужились их реализовать - это как раз специфика.
Но, как вы правильно указали, не так часто нужно делить БД на схемы.

Как верно написать рекурсивный запрос sql?

Указанная попытка - это решение совершенно другой задачи. А здесь нужно просто отсортировать:

SELECT
    employeeid
FROM employees
ORDER BY COALESCE(managerid,employeeid), CASE WHEN managerid IS NULL THEN 0 ELSE employeeid END

при условии, что employeeid всегда больше 0.
Но, вышезаданный вопрос остается, как теперь отличать employee от manager?

Какие БД используют крупнейшие торговые сети для хранения заказов?

Saboteur,

Короче я прикопался к вашему утверждению, что "высоконагруженное это не для sql"

Не-не, не так. Скорее "хорошего решения нет, поэтому используем то, что есть". И часто это будет sql.

Реляционки делают свою задачу, и если нужно ее делать быстро, ищутся решения для адаптации (кластеризация, шардизация)

Кластеризация или репликация помогут с чтением, но с записью никакого выигрыша. А шардирование не всегда применимо. Если к примеру, есть достаточно большая БД, что уже началась сильная деградация, а критерий шардирования не выбрать, то масштабировать не получится. Но это не значит, что можно будет в любой ситуации заменить nosql с бесконечным линейным расширением.

Какие БД используют крупнейшие торговые сети для хранения заказов?

Saboteur,

Отлично реляционные СУБД подходят для нагруженных систем. Просто не нужно путать когда для проекта подходит реляционная база, или другая. Это явно зависит не от "нагруженности", а от типа данных и архитектуры.
Некоторые вот даже TSDB путают с реляционкой.

Ага, отлично подходят, если не хранить много данных, и отказаться от большей части требований реляционнной модели. Речь не о том, что есть другое идеальное решение, речь о том, то что хотя они используются, это не значит, что они "отлично подходят". Будь оно так, то не внедряли бы зоопарк из различных решений, чтобы компенсировать проблемы реляционных СУБД.
И еще как выбор СУБД зависит от нагрузки, потому что вся архитектура зависит от нагрузки. Если это было не так, то мы бы всегда строго соблюдали реляционную модель, выставили бы serializable, писали бы транзакции как удобно нам, а не СУБД, и просто взяли бы бесконечно мощный 1 сервер с любой реляционной СУБД.

Какие БД используют крупнейшие торговые сети для хранения заказов?

Saboteur, не так уж и бредово, NoSQL показали, что есть альтернативы, не универсальная замена, конечно, но сами реляционные модель и СУБД уже давно плохо применимы для нагруженных систем. Т.е. теоретически все прекрасно, на практике железо не вывозит. Никто уже строго не следует реляционной модели, наоборот каждый раз думаешь, где еще ее можно нарушить, чтобы разгрузить систему (те же json и т.п.). Что касается реляционных СУБД, для них всегда был стандартом ACID, но по факту никогда не выполнялся. Консистентность соблюдается только частично, внутри СУБД уже забили на foreign keys, а на уровне системы консистентности вообще нет в момент времени, из-за множества ДЦ. Изолированность только условная, потому что serializable напрочь убивает всю производительность. Атомарность присутствует номинально, просто потому, что мы вынуждены писать максимально короткие транзакции, а изза этого Устойчивость как бы существует, но далеко не всегда поможет, т.к. все реализовано в обход. OLTP и OLAP это не просто способы организации БД, это утверждение "либо так, либо так, вместе не умеем", поэтому когда нужна система совмещающая обе функциональности появляется огромное кол-во проблем и ограничений при ее реализации. Поэтому, на практике если и применяют реляционные СУБД для высокой нагрузки, то уж точно, не потому что они хороши.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Александр Попов,

при существенном усложнении хранения и обработки

по этому поводу, более точно и подробнее Akina ответил.

Ну и в крайнем случае, мне проще в цикле применить mysql_real_escape_string() или аналог, ну или просто проэкранировать все одиночные кавычки в строках (не факт, что этого достаточно, но существуенно усложнит атаку).

Можно экранировать с помощью mysqli или PDO, и это будет примерно тоже, что и эмуляция подготовленных выражений в PDO. Просто экранировать кавычки очень ненадежное решение.
Решать вам, но нужно понимать риски подобных решений. Главное преимущество в защите от инъекций, это то, что подготовленные выражения разделяют код SQL и данные для него, и сервер не будет исполнять данные как код, теоретически это дает полную гарантию невозможности инъекций. С экранированием такой уверенности нет, что практика и подтверждает.

Как установить PHP в режиме отладки под Ubuntu?

Интерпретатор в консоли, и "в браузере", это совершенно разные программы, с разными конфигами, модулями и т.д.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Александр Попов,

А вы не знаете, почему был выбран разработчиками такой принцип?

Если вы про то, почему PDO использует по-умолчанию эмуляцию, а не настоящие подготовленные запросы, то это не очень хорошая реализация в MySQL. Там при высокой нагрузке не всегда во время очищаются сохраненные подготовленные запросы. В том же PostgreSQL такой проблемы не было. Но, может в последних версиях и починили.
Что касается отсутствия поддержки множественных запросов с подготовленными выражениями, не скажу. Вероятно, малая вероятность повторного использования при существенном усложнении хранения и обработки, да и подготовленное выражение это уже 3 запроса вместо 1го, т.е. никто не видит проблемы в нескольких запросах к серверу.

Если один человек вводит, наверное он не станет вводить данные, которые могут привести к инъекции.

Какой бы доверенный человек не был, завтра может быть другой или ктото получит его доступ. В любом случае, делать дыры допускающие инъекции плохая практика.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Akina, да, его цель защита от sql-инъекций, а для этого надо прям заморочиться с парсингом. Но это речь только про эмуляцию.
Классический пример, баг PDO, когда в китайской кодировке использовался особый символ кавычки, который парсер PDO воспринимал как кавычку, а СУБД нет, или наоборот. В итоге, проходили sql-инъекции.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Ипатьев,

Vitsliputsli, но PDO-то поддерживает. Так что пользователь PDO может продолжать использовать prepare.
Парсер в PDO вообще ни разу не полноценный, а простая заменялка плейсхолдеров. В том числе для обеспечения поддержки эмуляции.

Поддерживает, но автор использует эмуляцию.
Он для эмуляции и создан, для prepared он и не нужен, там уже СУБД сама разберется. Полноценный не в смысле, что он всю грамматику разбирает. Но он и не просто заменялка, так как на нем полноценная защита от sql-инъекций.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Александр Попов, MySQL не поддерживает множественные запросы для подготовленных выражений:
https://dev.mysql.com/doc/c-api/8.0/en/c-api-multi...
https://dev.mysql.com/doc/refman/8.4/en/prepare.html
но вы попрежнему можете их использовать без подготовленных выражений.

Akina,

Да не будет библиотека этого делать! К тому же просто разделить по точке с запятой - это гарантированно всё поломать, если указанный символ входит в состав строкового литерала. И что, теперь цеплять в библиотеку полноценный парсер?

Что написано, то и передаётся серверу в том виде, в каком написано. Это его парсеру разбираться.

В библиотеке PDO уже присутствует полноценный парсер SQL. Мало того, по-умолчанию для MySQL именно он и работает (а так как в коде выше автор не отключал эмуляцию подготовленных выражений, то и в его случае тоже). MySQL плохо работает с prepared statements и вероятно поэтому PDO предпочитает их не использовать.

Memory limit в Clickhouse. Как бороться?

При попытке сделать к ней Left join или просто при выборке с сортировкой по какому-либо полю

Если просить вернуть все 200млн, то памяти скорее всего и не хватит.

Как получить имя переменной из строки?

Алексей Денисов, зачем кешу тратить время на чтение с диска? Каждый раз по 200 байт.

Вместо переменных и массивов - сделал отдельно файлы с именами 123, 578, 015 и т.д.
(на самом деле HEX значения - 6 знаков).
Имя = один из GET параметров запроса

Т.е. пользователь может посмотреть любой файл, имя которого укажет в GET параметре?

Как получить имя переменной из строки?

Алексей Денисов,

но в некоторых переменных содержатся строки более 2000 символов, а самих переменных может быть далеко за 100,
это какой массив тогда получится.

И что смущает? Массив получится такой как и должен. 200Кб это немного, а с переменными будет примерно те же 200Кб.
Для массивов данных в php есть структура массив, так почему ее не использовать?