Есть ли в PHP готовый инструмент для получения элемента массива вложенность которого хранится в другом массиве?

Сергей delphinpro, например?
Да, вы можете для понятия отсутствие значения, придумать 2 значения, но это абсурдно. Представьте, что вы так сделали, а затем вам нужно передать этот элемент массива дальше в функцию, потому что обрабатывать значения должна она, по принципу ответственности. Что вы будете делать? Вместо простого оперирования примитивами, введете объект с значениями null и псевдо null? Можно, но кроме запутывания кода, это не даст ничего.

Есть ли в PHP готовый инструмент для получения элемента массива вложенность которого хранится в другом массиве?

Действительно не понятно зачем собрались. Но все же...
Ипатьев,

И точно так же как там, здесь нельзя утверждать, что элемент не найден. Элемент может быть найден, но быть равен null.

Сергей delphinpro,

Именно поэтому для проверки наличия ключа стоит использовать специально предназначенную для этого функцию array_key_exists

Null - это отсутствие значения.
Null как значение типа null в php - это значение отсутствия значения - противоречие, оксюморон, костыль который нужен только для передачи отсутствия значения в значении. Поэтому обозначать отсутствие значения через null - это ровно то, для чего он предназначен. Да, конечно, можно присобачить эксепшены и получить много бессмысленного кода, но зачем? Это лишь усложнит код и добавит абсурда. Так что все корректно в коде maksam07.

Не могу обновить софт, как правильно сделать?

Михаил,

как софт поставился там и работал до сего дня

Git это инструмент разработки, а не деплоя. Т.е., на машине для разработки затягиваете новую версию и готовите релиз, со всякими

да, менял, по инструкции автора

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

"аналог" языка bash?

ZailoxTwink, существует множество командных процессоров: sh, bash, zsh, csh, tcsh, ksh, dash. Есть еще posix-несовместимый fish, позиционирует себя как user-friendly, а в Ubuntu вообще многие скрипты заменили на python. Но они все появились не один десяток лет назад, не знаю такого, который появился недавно.

просто синтаксис if else while for и т.п. сложноватый

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

Как дать права на домашнюю папку другому пользователю?

как минимум, чтобы просматривать директорию нужны права x

Как устранить ошибку 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-инъекции.