Я бы в конкретном месте отказался от основных фич ORM, и сделал на основе сырых SQL запросов.
То есть Вы понимаете цель вашей задачи:
А. Проверить запись в БД
Б. Сделать апдейт по условию
Подготавливаете задачу. В итоге в БД уйдую запросы:
А. SELECT * FROM table WHERE id IN (X, Y, Z);. Где X, Y, Z - соответственно идентификаторы записей, которые Вам нужно получить.
Б. Обработали данные, подготовили, отфильтровали, отправляем запрос.
UPDATE table
SET row = CASE
WHEN id = X THEN 'A'
WHEN id = Y THEN 'B'
ELSE row
END
WHERE id in(X, Y)
Так Вы получите один два запроса на всю пачку, вместо двухста (или более).
neosistema, Посмотрите внимательно на ссылку. Выше я писал, что можно задавать изображению любые размеры. В ссылке есть параметры отвечающие за высоту и ширину. Можете задать туда разные значения и вытащить тот размер, который вам нужен
"А судьи кто?"
Я плачу за тариф в 250 мбит/с. У провайдера есть тариф в 150 мбит/с. Вот мне и надо понять - а не лучше ли перейти на него? Если с основного устройства я всё равно не могу получить заявленную скорость?
HDD у меня если что нет. Стоит SSD со скоростью записи в 450мбит/c, последовательно.
Драйвера поставил последние, с официального сайта. Обновления давно вырублены. При питании от сети и из убунты удалось достичь скорости в 130 мбит/с, уже лучше, но до 250 всё так же далеко...
Василий Банников, Вооот, спасибо! Теперь стало понятно. Там вся соль в том, что эти тесты писали не мы, они видимо автоматически генерятся Laravel-ем. А далее, уже Laravel Breeze как оказалось создал шаблонные unit-тесты, которые и не проходились, и фейлили запуск. Проблема лишь в том, что о самом их существовании мы узнали только что, из файла в workflows)))
Ваши наблюдения верны - мне действительно не нужны эти тесты и я хочу их отрубить.
Вопрос задаю по очень банальной причине - интерфейс github-а, вообще не user friendly в плане настроек, и я просто напросто не знаю как их отрубить при PR. (Этот вопрос сформулирован в моём описании)
А гугл ничего толкового не выдаёт на мои запросы. Так что "покажите пальчиком" пожалуйста)))
Либо ссылку на релевантный гайд по их отрубанию, если можно
Спасибо! В глубинных настройках нашёл режим перехода в гибернацию из сна после 180 минут, отключил, теперь всё норм. Другой вопрос почему гибернация не работает как гибернация, но да ладно...
Руслан ., Да, активный заказ не является атрибутом пользователя, он является просто внешним ключом заказов, создавая таким образом ту самую вторую связь один-к-одному)
Но так, спасибо, в целом стало понятнее. Единственное, что не могу понять момент - неужели, нигде во время разработки не появляются такие варианты, когда нужно две совершенно разных связи между таблицами, что такого нет ни только в теории, но и при беглом гуглении?
То есть Вы понимаете цель вашей задачи:
А. Проверить запись в БД
Б. Сделать апдейт по условию
Подготавливаете задачу. В итоге в БД уйдую запросы:
А.
SELECT * FROM table WHERE id IN (X, Y, Z);
. Где X, Y, Z - соответственно идентификаторы записей, которые Вам нужно получить.Б. Обработали данные, подготовили, отфильтровали, отправляем запрос.
Так Вы получите один два запроса на всю пачку, вместо двухста (или более).
Если особо запариваться с сырым SQL не хочется, то можете посмотреть в сторону встроенных ELOQUENT ORM методов. Судя по описанию, делают примерно то же самое, насчёт итоговой эффективности, сказать не могу, нужно проверять:
https://laravel.com/docs/11.x/eloquent#chunking-results
https://laravel.com/docs/11.x/eloquent#cursors