VlLight,
Выделите ту часть, которая создаётся один раз и в принципе не должна меняться или удаляться, сделайте ей отдельный бэкап с хранением только двух последних полных бэкапов (и связанных с ними диффов и инкрементов). Запретите удаление и изменение этих фйлов средствами системы или сделайте скрипт, который регулярно проверяет эту часть и восстанавливайте измеённые файлы из бэкапа.
Для остальной части определитесь, сколько времени вам реально нужна история файлов. Как правило, если отсутствия файлов не заметили в течение года, то это были не такие уж и нужные файлы.
А reverse incremental backup я видел только у Veeam и только в контексте бэкапа дисков виртуальных машин.
cajka-d, Тогда только по шагам трассировать, откуда и что возвращается. Начать с метода роутера и постепенно погружаться в вызовы функций. Насколько я вижу в документации на Laravel, заголовки подключаются к ответу отдельным методом header или withHeaders.
cajka-d, Возможны разные варианты.
Убедитесь, что web-сервер не устанавливает заголовки принудительно.
Проверьте по логам, что до вызова функции header ничего не выводится. Если это не так, то в логе должно быть предупреждение "Headers already sent".
viktorross, Не так - список категорий через запятую в одном поле. Для связи многие-ко-многим надо использовать отдельную таблицу.
По ошибке - покажите пример с данными, запросом и ожидаемым ответом.
Не совсем. Ещё допускаются колонки, где в каждой группе остаётся только одно значение. При этом не обязательно, чтобы группировка шла по первичному индексу.
То есть, если в базе только Василии и Семёны, при этом все Василии - Алибабаевичи, а Семёны - Семёновичи, то при группировке по имени вполне можно выбрать отчество без агрегатной функции.
Вот только такая таблица уже не будет в нормальной форме, поскольку содержит функциональную зависимость от неключевого поля.
Действительно, фигню написал.
Предположим, что у пользователя 10 записей с completed == true.
id какой из этих записей вы рассчитываете получить в сгруппированной строке и почему именно этот id?
hikamurachi, Вопрос в том, что нет никакого смысла объединять преподавателей (teachers) и студентов (students) по их id в базе данных, даже если эти id и полностью совпадают.
Совпадение набора данных, особенно числовых, не означает совпадение смысла этих данных.
JOIN можно выполнить по любым наборам полей, вопрос лишь в полученном результате.
Как думаете, две таблицы teachers (id, name) и students (id, name) можно объединять по id, если там одинаковые данные?
Выделите ту часть, которая создаётся один раз и в принципе не должна меняться или удаляться, сделайте ей отдельный бэкап с хранением только двух последних полных бэкапов (и связанных с ними диффов и инкрементов). Запретите удаление и изменение этих фйлов средствами системы или сделайте скрипт, который регулярно проверяет эту часть и восстанавливайте измеённые файлы из бэкапа.
Для остальной части определитесь, сколько времени вам реально нужна история файлов. Как правило, если отсутствия файлов не заметили в течение года, то это были не такие уж и нужные файлы.
А reverse incremental backup я видел только у Veeam и только в контексте бэкапа дисков виртуальных машин.