{"error": 0, "info":"success!"}и проверять if( data.error == 0 )
url: '<?= base_url("logs") ?>/save_error.log', - какой-то странный урл, похож на файл лога ))) хотя это конечно же можно прописать в роутинге как экшн.data: dataEdit - надеюсь вы понимаете что сюда сначала нужно что-то добавить, и желательно строку
вы хотите сказать проверять сессию при выполнение какого либо действия php скрипта с бд?Почему именно с бд? Вообще любого действия внутри админки без проверки авторизации НА СЕРВЕРЕ делать нельзя.
1. Вопрос был про то, что нужно делать в случаях, когда объект получает в конструктор входные данные для инициализации, но возникают случаи, когда объект не может быть инициализировать (с которым нельзя дальше работать), из-за разных причинТут как раз сильно зависит от причин. И в конкретно этом случае ваш подход хреновый. Не может быть хорошим решением выборка в 200 запросов циклом. Инфа 146%.
Представьте себе - есть правило, по которому данные ссылочного типа не удаляются. Да, оно чисто архитектурное и имеет косвенную связь с 3 нормальной формой. Есть даже специальный конструкт - внешний ключ, который определяет поведение при удалении связанных данных, и по умолчанию он прерывает удаление.На самом деле удалять ничего не надо было, просто достаточно пометить ненужные записи как неактивные.
Вы "Куратор тега PHP" и пишете такие вещи.
А кто сказал, что нужно деактивировать ? Это какое-то правило проектирование БД?
Мы работаем с CMS, в которой уже вся архитектура такая, какая есть.Ну, для начала надо бы упомянуть что вы работаете с CMS, это бы многое прояснило, хотя все еще не вижу причин не изменять штатные объекты или наследоваться от них.
любая (адекватная) CMS может обновляться, и в любой момент может меняться структура БД.Нет, или адекватная, или меняться структура. Тут без вопросов, обратная совместимость изменений - базовый аспект для любого адекватного приложения. Только смена парадигмы и какой-то жесткий факап в базовой структуре может сподвигнуть на такие меры как изменение архитектуры вплоть до несовместимости интерфейсов.
Советчики, которые рекомендуют работать напрямую c sql, и не использовать орм, чтобы оптимизировать выгрузку в 200к записей - это вообще... диванные эксперты.Ну, на промышленных системах так часто делают, ибо отчеты реально быстрее сформировать 1 сложным запросом, нежели 10 простых + логика на бэкенде. Но в основном все же орм может все это своими силами. Просто нужно хоть чуточку в нее уметь.