holllop, смотрите, все очень и очень просто:
вы хотите вывести o.order_id, w.id_work, e.n_plan, при этом уникальных order_id у вас 3.
Но проблема в том, что уникальных w.id_work у вас 5, и посгря без подсказки понятия не имеет, как 5 запихнуть в 3.
И эту подсказку в запросе необходимо указать.
Собственно ошибка "столбец "w.id_work" должен фигурировать в предложении GROUP BY или использоваться в агрегатной функции" о том и говорит.
что можно сделать:
GROUP BY w.id_work и 5 в 3 запихивать на стороне клиента базы
исключить w.id_work из запроса
придумать, найти (если есть) или написать (если нет) соответствующую аггрегатную функцию (к примеру, конкатенировать w.id_work через точку с запятой и возвращать клиенту стрингу)
P.S. хамить на уточняющие вопросы - харам. То что вы называете "многовложенность или хз как это называется" - это и есть аггрегатные функции. Самый простой пример SUM() или COUNT().
Для более конкретного ответа опишите логику, в каком виде вы хотите получить несколько w.id_work у одного o.order_id в выборке.
Не имел дел со Spring Boot, но на ASP .NET Core неплохо работает следующая схема:
В шареной либе описываем модель ошибки, коды сообщений, сообщения и их локализацию, если надо.
Там же описываем middleware для обработки ошибок.
В сервисах встраиваем middleware в пайп обработки запроса, и теперь в любом месте можно сделать throw MyCustomEx(ErrCode.SOMETHING_WENT_WRONG);
Еще можно в middleware обработки ошибок через DI контейнер добавлять специфичные для сервера коды и сообщения, чтобы не держать их в общей библиотеке.
#, лучше так, чем в условном фортране, где вот такой пример совершенно легален
integer i ! не инициализировано, автоматом не зануляет, условно i = 0xdeadbeef
i = i + 1 ! обычный инкремент
print(i) ! конечно же не 1, а 0xdfadbeef или 0xdeadbef0 в зависимости от byte order
Антон, в первую очередь нарисуйте самому себе схему того, что у вас происходит, например
фронт(браузер) (1) -> интернет -> фронт(сервер) (2) -> бэк (3) -> база (4)
в этой схеме если запросы исполняет (2), то миксед контент не проблема, достаточно настроить, чтобы бэк на машине 3 слушал только машину 2, а база 4 давала подключиться только бэку
если же запросы идут от браузера (1), то бэк (3) должен слушать запросы извне (как правило не сам, а через reverse proxy), и тут уже нужен и SSL (чтобы не было Mixed) и иногда CORS (если бэк по какой-то причине на отдельном домене).
FLAIMS, нового в этом бюджете ничего не будет, но на рынке б/у к примеру Lenovo Thinkpad T480 можно посмотреть, в районе 30к как раз будет.
Проц сразу стоит выбрать по требованиям, а память можно обновить после.
FLAIMS, а зачем именно мак для web разработки? обозначенном бюджете можно найти например пробук или синкпад поколений этак на 4-5 свежее и добить памяти до максимума, поставить windows или linux по вкусу
Имхо это скорее список того, с чем точно тестировалось.
не вижу причин, по которым 2 или 4 тб не завелся бы - это не оперативка, контроллер на самом диске же.
Было бы неплохо понять, как Cloudflare определяет браузер, поскольку, например, куки и юзер-агент вы в своем приложении вольны выставить произвольно, добыв их из того же хрома.
в данном случае даже для 3d не используется, ЕМНИП - BT headphones - отдельный выходной девайс, и наличие-отсутствие карточки (и даже встройки) и фичей на него никак не сказывается.
Роман, поясните мысль, пожалуйста. Например в ситуации, когда клиент не делал запросов за период времени ATLifetime < Tau < RTLifetime (человек не обновлял страницу, не нажимал кнопок и т.п.), как тогда следует поступать?
Dudder, когда клиенты с истекшим АТ получили 401, это значит что авторизация не прошла - и в методе с AllowAnonymous, если вы передаете токен, Identity.IsAuthenticated тоже будет false у юзера, т.к. время жизни токена истекло.
Как я поступал в подобной ситуации: на RefreshUrl отправляем модель с AT и RT, плюсом один из клеймов AT - SessionId.
Для разбора AT написан свой хелпер, который создает JwtTokenHandler с настройками, идентичными AddAuthentication, но с отключенной проверкой времени жизни токена.
В данной схеме RT - не JWT, а просто уникальный идентификатор, который при рефреше меняется - чтобы не получить два рабочих AT на сессию.
Как вариант можно сложить все нужные клеймы в RT (тоже JWT), тогда отправлять AT клиенты не должны вовсе, но свой TokenHandler для разбора RT и извлечения клеймов вам все равно понадобится.