• Хелпер Laravel dd() возвращает ошибку 500?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    Конкретно по твоему случаю я не знаю, но у меня такое было из-за корсов.

    Запрос для апи должен вернуть заголовки CORS которые не могут быть возвращены, т.к. ты прервал программу с помощью dd(). Браузеры в итоге пишут вроде 500, а вкладки "контент" вообще нет. Причем если напрямую в браузер адрес апи вбить то ответ есть. Но есть же POST запросы, которые надо расширением делать заголовок на POST менять или писать "псевдо-пост" типа "если есть флаг $_GET['method']=POST то воспринимать как пост. Для дебага конечно, на проде нельзя.

    Чтобы их вернуть нужно "как-то" после dd() вернуть ещё респонс и отправить его. И это только пол-проблемы, т.к. запроса будет два. И заголовки нужно вернуть и в OPTIONS запросе (одни) и в обычном запросе (другие), на чем часто горят задницы многих разработчиков типа "задолбался с cors". Ну да, там и вправду творческое задание. Только лучше иметь установленный файрфокс, чтоб дебажить, вслепую быстро доводит до срыва.

    Один из способов - зайти в доку symfony/var-dumper, сделать маленький класс из двух методов и там с помощью varcloner вернуть вывод dd() в переменную. После этого вместо dd() вывести его результат через echo, и позволить запросу завершиться (но это не всегда возможно, если ты поймал критическую ошибку - в этом случае управление перейдет Exceptions\Handler.php (в ларе) или если скрипт очень длинный, тогда будешь ждать минуту каждый раз чтоб дебагнуть.

    Второй способ - вместо dd() бросать исключение и его обрабатывать в Handler.php, который формирует ответ-исключение (может делать, если режим сайта дебаг и тд.) там тоже можно преобразовать в другой вид. Но опять же хотя обработка исключений это стандартный процесс для большинства фреймворков - мне его задумка не очень нравится просто потому, что у нас есть контроллер с респонсами, а тут еще одна приблуда, которая до кучи еще и настроена по-своему во имя возможностей которыми почти никто не пользуется. Но тем не менее код выполнится уже на этапе response->send() а значит отправятся нужные заголовки, а потом выведется dd() который написано выводить если "исключение такое-то".

    Обычный трайкетч в файле index.php часто делает то же самое и более податлив к допилам, чем разбираться как это же делает "настроенный кем-то обработчик" который умеет два метода - render() и notify() который один для отрисовки, второй для отправки куда-то, создается ощущение, что "больше ничего нельзя", а код это все таки свобода мысли.

    Есть ещё совсем уж злой способ - register_shutdown_function(), где ты принудительно вернешь пустой респонс с 500 ошибкой, но вот вывод dd() придется прокидывать через костыль. И потом register_shutdown_function() особенно весело мирить с каким-то шаблонизатором типа Plates, Twig или Blade, которые по дефолту как правило просто не выводят исходник html, если поймают внутри ошибку тупо завершая ob_get_clean() вместо ob_get_flush(), в итоге эксепшен есть, а dd() нету, т.к. он был в хтмл, который остановился и очистился.

    Оба варианта не очень логичны и костыльны, зато позволяют потом в том же постмане или браузере видеть в апи не json, а нашу dd() шку. Там помучаться надо немного, но сильно сократит время на создание полного зеркала апи в постмане или сваггере и слежения за ним. Все-таки сказать человеку "нажми F12" против убить день на то, чтобы он выучил возможности сваггера, а потом ты их выучил, а потом ты их описал, потом понял ограничения - лишние действия под сомнительный итог "у нас документация по канонам". Все равно придется объяснять новым как что работает.
    Ответ написан
    2 комментария
  • Правильно ли я спроектировал логическую модель базы данных?

    @Akela_wolf
    Extreme Programmer
    В целом выглядит прилично. У меня 2 замечания:
    1. "Кольцо" между subs и projects: subs.project_id ссылается на project, project.sub_id ссылается на sub. Мне так кажется что-то одно тут лишнее.
    2. Связь между projects и modules вида "много-много". У вас реально один модуль может входить в несколько проектов? Если да, то ОК. Если нет - то я бы убрал промежуточную таблицу.
    Ответ написан
    1 комментарий
  • Правильно ли я спроектировал бд рецептов на ER-диаграмме?

    vabka
    @vabka
    Токсичный шарпист
    1. Очень странно выглядит, что БЖУ привязано к блюду, а ккал - к рецепту.
    2. Между рецептом и ингредиентом связь 1-к-1, а должно быть 1-ко-многим.
    3. Кол-во ингредиентов лишнее, тк может быть посчитано из количество связей между ингредиентами и рецептом. Во всяком случае, оно точно не должно указываться в блюде.
    4. Рецепт разве не инструкция?
    5. Раз уж у нас тут книга рецептов, то где шаги по готовке? Даже описания никакого у рецепта нет. Даже заголовка или названия.
    6. Граммовки у ингредиентов могут различаться от одного рецепта к другому, так что должны быть указаны в строчке рецепта.

    Попробуйте сначала построить модель своей предметной области, вычлените из неё сущности и данные в них, а потом уже стройте схему на уровне БД.
    Ответ написан
    Комментировать
  • Конвертация типа и условие?

    @Akina
    Сетевой и системный админ, SQL-программист.
    Почему не просто

    SELECT *
    FROM email
    WHEN public.email.campaign_id IS NULL


    ?

    Ну или если вдруг вот офигеть как нужна эта дополнительная колонка, то

    SELECT *, 'false' AS campaign_id_bool
    FROM email
    WHEN public.email.campaign_id IS NULL


    нужно, чтоб были значения и тру и фолс в зависимости от того пустое ли поле


    SELECT *, 
           CASE WHEN public.email.campaign_id IS NULL
                THEN 'false' 
                ELSE 'true' 
                END AS campaign_id_bool
    FROM email

    Или так:
    SELECT *, 
           ELT(1 + public.email.campaign_id IS NULL, 'true', 'false' ) AS campaign_id_bool
    FROM email
    Ответ написан
    6 комментариев