А вообще странно то что функция json_encode() не хочет принимать строку.
php > echo json_encode('q');
"q"Да у меня там JSON длинный. А создавать новый массив для сериализации как то не хочется.
Тем более это вопрос экранирования и очистки.
printf "echo 1 \n echo 2" | bash На тестовом стенде стоит Ubuntu 22.04.1, именно эта конструкция в Zabbix не работает, если убрать -e - работает.
А я сделал так, чтобы все классы лежали в одном файле и все работало.
class MyClass
{
public function myFunction(): string
{
return get_class($this);
}
}
class FirstClass extends MyClass {}
class SecondClass extends MyClass {}
foreach (['FirstClass','SecondClass'] as $className) {
var_dump((new $className)->myFunction());
};class MyClass
{
public function __construct(private string $name) {}
public function getName(): string
{
return $this->name;
}
}
foreach (['first','second'] as $var) {
$$var = new MyClass($var);
};
var_dump($first->getName());
var_dump($second->getName());class TestClass {
private $testVariable;
}
Блокировки никуда не денутся в этой схеме, но из-за простоты 1 запроса, все должно работать быстро и особых проблем не возникнет.
Вообще, даже если у автора сотни операторов на проекте, это не будет представляться проблемы во время работы, т.к. обращаться за заявками они будут в разное время. Но есть пиковый момент, когда операторы в ожидании и заявки поступают в обзвон. В этот момент все операторы ломятся на сервер за заявками, ктото успевает заблокировать 1 запись под update, остальные блокируются и ждут, update завершается, остальные получают ответ "приходите позже". Разумеется, эти запросы размазаны по времени, но чем больше операторов и чем медленнее СУБД, тем будет больше очередь. Кроме того, когда "вернулось ноль номеров", это может значит, что заявки закончились, тогда врубается пауза чтобы не кошмарить СУБД запросами, по истечении этой паузы все опять ломанутся за заявками, а из-за пауза ожидание увеличивается.
Повторюсь, из-за скорости работы одиночного update, все должно быть норм, но если нет, то можно паузу делать немного рандомной, либо проверять попал оператор на блокировку или действительно закончились заявки и в первом случае не ждать, а снова мучить сервер.
Теоретически, здесь хорошо подходит select for update skip locked - когда мы не ждем освобождения блокировки и уходим ни с чем, а просто берем следующую запись. Но нужно попробовать и убедится, что в конкретной СУБД все работает корректно.