В том-то и загвоздка, что подобные, а не такая же и помногу раз в секунду, чтобы имело явный смысл запариться и считать на стороне СУБД. В следующий раз надо будет заменить что-нибудь другое в другом месте - и обработчик для этой задачи подойдёт чуть менее чем никак.
А знакомый язык, да с полноценными регулярками - простое и понятное решение. СУБД может помочь с предварительным фильтром, чтобы не обрабатывать данные, в которых подстроки и нет вообще.
Кого поставить на апач? Наверняка ваш nginx уже собран с этим модулем, как, например, в репозиториях debian. Вот и допишите в конфиг использование этого модуля. Ну а если не собран - то придётся пересобрать кастомный nginx.
Клонировать каждый объект коллекции в отдельности. Например,
public static function getItems(){
return array_map(function($el) {
return clone $el;
}, self::$arItems;
}
Статический класс здесь значения не имеет. По ссылке передаются сами stdClass
WeReng: это расходник. Всегда считайте, что можете в любой случайный момент времени потерять все на него записанные данные.
Плюсы и минусы:
сдать по гарантии - до 45 суток его могут держать в СЦ согласно этому самому ЗоЗПП (насчёт условий выдачи подмены на этот срок не помню точно, надо уточнять). Минимум и в среднем - в зависимости от СЦ. Есть вероятность, что они сами запустят это же самое восстановление, диск исправится и его же вам вернут через пару дней. Но есть и вероятность, что диск вам заменят на новый с новой гарантией.
запустить программу самому - соответственно, если поможет, то у вас уже не будет повода обращаться в СЦ. Если не поможет - то в СЦ всё равно (и повыше вероятность замены).
Вот по-моему и вся разница.
Hello1: проблема в формулировке. Накопитель должен читать-писать свой номинальный адресуемый диапазон LBA. Если этого не происходит либо происходит с ошибками - да, это гарантия. Если же всю свою адресуемую ёмкость диск читает и пишет - значит диск исправен. И никого не волнует, что это достигнуто резервной областью диска и ремапами неисправных секторов в эту область. Если просто в каком-то там SMART значение какого-то там параметра не 0 - это не является дефектом.
> Это может быть как S-ATA1 (в таком случае покупка SSD выглядит неоправданной тратой денег)
Оправданной.
Да, в этом случае не нужен топовый диск. На десктопах всё-таки не такие жёсткие требования к случайному вводу-выводу, где даже современные топовые SSD едва преодолели отметку в 50мб/с (случайное чтение, глубина очереди 1).
IOPS же штука полезная только с указанием методики тестирования. И не имеет ровно никакого отношения к времени доступа. Можно и на одном SATA HDD намерить 300-400 IOPS из физически возможной сотни. https://habrahabr.ru/post/154235/
На указанные производителем цифры можно вообще не смотреть. Там всё равно будут пиковые цифры с идеальных условий, если вообще реальные, а не с потолка переписали.
Передача данных на стороннюю машину - зачем вообще делать синхронно? Кладёте сообщение в очередь. Демон, который очередь разгребает, на dev вообще не запускаете (кстати, очень простой и дубовый демон, который становится куда легче отлаживать, т.к. выполняет только 1 задачу). Можете подцепиться к очереди и посмотреть, всё ли правильно оформлено для отсылки на сторонний сервис. Не говоря о штатной работе, если удалённая машина недоступна - демон разгребёт очередь попозже.
И это же хороший пример конфигов, которые на dev-машине вовсе неуместны. По крайней мере во включенном состоянии. Даже в синхронном режиме работы запросы просто заворачиваете на эту же локальную машину с простой и глупой эмуляцией API и ведением логов для разбора, правильный ли запрос был отправлен.
Хотите закомментировать временно - зачем вообще в гит коммитить? И зачем хотите комментировать? Может, это должна быть директива конфига на самом деле, отключенная в dev-окружении?
Конфиги вы должны иметь возможность создавать разные. Реализовать можно разными путями - через переменные окружения сообщать, конфиги какого окружения подтаскивать; класть в гит глобальный дефолтный конфиг, а в прописать .gitignore локальный конфиг, который собой может заменять некоторые директивы из глобального и всякие другие способы. В частности, продовых конфигов в гите может не быть вовсе.
dev и prod на разных платформах - вообще порочная практика. Используйте vagrant с окружением, наиболее близким к проду. Ну кроме случая, когда вы пилите что-то коробочное, что должно работать на любых чайниках.
Ну ладно. Значит берёте исходник и раскуриваете его. https://github.com/zendframework/zf1/blob/master/l... ничего примечательного, что-то неверное генерируется для _execute. Метод public, так что берите стектрейс и читайте промежуточный код, где поведение идёт куда-то не туда.
А знакомый язык, да с полноценными регулярками - простое и понятное решение. СУБД может помочь с предварительным фильтром, чтобы не обрабатывать данные, в которых подстроки и нет вообще.