Prometheus + Grafana

хотя, смотря чего метрики

камон можно и графану

камон можно и графану

так собирать то чем то надо

не эластиком же

https://www.journaldev.com/2676/spring-mvc-interceptor-example-handlerinterceptor-handlerinterceptoradapter

посоветуйте метрики для петпроджекта

^

можно и в эластик слать

Для пета и сингл нод influxdb может быть вполне. Есть докер образ и графана в него умеет

Ну или Прометей если все серьёзно

Ластик -- хз как с него строить график в какой-то морде

@frostbit насчет _правильной_ реализации — https://www.youtube.com/watch?v=fpyub8fbrVE

Вот да, видел. Будет здорово, когда сделают. Я согласен, что это должно быть куда лучше текущих корутин в котлине и всяких Quasar.

Вот да, видел. Будет здорово, когда сделают. Я согласен, что это должно быть куда лучше текущих корутин в котлине и всяких Quasar.

А что с корутинами в котлине не так?

А что с корутинами в котлине не так?

То, что они работают поверх текущей JVM - это достижение. Но у таких корутин нет своего стека (как в Go или Lua), а только эмуляция через коллбеки (которые лежат в хипе). Как следствие, у исключений, например, не всё так просто с stack trace.

Сорри за оффтоп (:

Бомбануло.

То, что они работают поверх текущей JVM - это достижение. Но у таких корутин нет своего стека (как в Go или Lua), а только эмуляция через коллбеки (которые лежат в хипе). Как следствие, у исключений, например, не всё так просто с stack trace.

В одном предложении сравнивать котлиновские корутины с go, а в следующем говорить про стектрейсы - это сильно))

В одном предложении сравнивать котлиновские корутины с go, а в следующем говорить про стектрейсы - это сильно))

Что не так?

их кто-то собирается на уровне JVM реализовывать?

их кто-то собирается на уровне JVM реализовывать?

имхо лучше бы этим и занялсь вместо всяких jigsaw

имхо лучше бы этим и занялсь вместо всяких jigsaw

ради того чтобы у тебя был правильный стек трейс? :)

ради того чтобы у тебя был правильный стек трейс? :)

Чтобы код не покрывался suspend-функциями и на каждый вход в такую функцию не создавался объект в хипе. Страница Project Loom ссылается на интересную статью http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Чтобы код не покрывался suspend-функциями и на каждый вход в такую функцию не создавался объект в хипе. Страница Project Loom ссылается на интересную статью http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Он на каждый вход и не создаётся.

Он на каждый вход и не создаётся.

Я имею в виду первый вход. Т.е. на каждый вызов.

Я имею в виду первый вход. Т.е. на каждый вызов.

Не понял.

Не понял.

На самом деле не так: suspend-функция может не создавать Continuation, если реальной приостановки не произошло. Я не знаю точно, если ли сейчас там такая оптимизация, но кажется да. Получается, что если все функции в коде просто пометить как suspend, они не начнут создавать мусор в хипе.

На самом деле не так: suspend-функция может не создавать Continuation, если реальной приостановки не произошло. Я не знаю точно, если ли сейчас там такая оптимизация, но кажется да. Получается, что если все функции в коде просто пометить как suspend, они не начнут создавать мусор в хипе.

Ну да.

я еще на 9 то не пересел

Мы и на 8ю не все еще переползли )

Просто отделов очень много, и пользователь не во всех сразу, а надо получить его отделы и потом авторизовать по отделу

А почему бы на каждые отдел не выдать роль? Пользователь логинится, ему в jwt token прописываются все роли, он логинится, на основании этой инфы показываешь список отделов. Ну или из базы берешь. Зачем в два этапа?

А почему бы на каждые отдел не выдать роль? Пользователь логинится, ему в jwt token прописываются все роли, он логинится, на основании этой инфы показываешь список отделов. Ну или из базы берешь. Зачем в два этапа?

Я под 12 летнюю базу пишу веб-сервис

Структуру базы менять нельзя

Мы и на 8ю не все еще переползли )

котлин запиливайте))

как весело работать на 6-7ке и не впасть в уныние?)

нам кокаин выдают

нам кокаин выдают

норм подход))

дешевле чем легаси на 8-ку перевести

нам кокаин выдают

О, а что за компания?) Есть вакансии?

дешевле чем легаси на 8-ку перевести

???))

О, а что за компания?) Есть вакансии?

оп-оп, вакансии есть, но не на наш проект

не хочу чтобы потом вруном на весь чат назвали

Если кокаин выдают на всех проектах, то без разницы )

глядя на некоторых коллег, я думаю что там скорее "хмурый".

Это на EE проекты что ли?

Это на EE проекты что ли?

100% ))

на jsf

с майбатисом

Это на EE проекты что ли?

еще же госы есть

на jsf

тогда уж на виките

так это...openjdk запилили lts

c 8кой до 20 года)

еще меньшая вероятность того что народу будет переходить на 10ку)

еще меньшая вероятность того что народу будет переходить на 10ку)

у нас решили что проще на скалу перейти 1 раз, чем каждые полгода шаманить с переездом

у нас решили что проще на скалу перейти 1 раз, чем каждые полгода шаманить с переездом

у скалы же с обратной совместимостью не очень

или пофигу?

на скалу 2.12.1...... навсегда

у скалы же с обратной совместимостью не очень

у скалы сиснтаксис норм, можно на 8-ке сидеть до 20-го года

у скалы сиснтаксис норм, можно на 8-ке сидеть до 20-го года

можно в котлин

Добрый день. Коллеги, поделитесь опытом проектирования классов. У меня часто в приложении есть класс, который описывает заказ и среди его полей есть массив строк заказа: class Order { String orderNum; // Номер заказа List<OrderRow> rows; // Строки заказа } При этом обычно OrderRow содержит ссылку на Order: class OrderRow { Order order; } С одной стороны это удобно. Если OrderRow реализует метод сохранения в БД, я без проблем могу это сделать. Структура sql таблицы будет примерно такая: table order_t [ order_num (из Order) , .. (прочие данные из OrderRow)] Я не уверен что это хороший подход. Возможно принято делать так, что бы OrderRow ничего не знал о своем родителе Order? Но тогда мне все время нужно будет таскать за собой отдельно Order.

Добрый день. Коллеги, поделитесь опытом проектирования классов. У меня часто в приложении есть класс, который описывает заказ и среди его полей есть массив строк заказа: class Order { String orderNum; // Номер заказа List<OrderRow> rows; // Строки заказа } При этом обычно OrderRow содержит ссылку на Order: class OrderRow { Order order; } С одной стороны это удобно. Если OrderRow реализует метод сохранения в БД, я без проблем могу это сделать. Структура sql таблицы будет примерно такая: table order_t [ order_num (из Order) , .. (прочие данные из OrderRow)] Я не уверен что это хороший подход. Возможно принято делать так, что бы OrderRow ничего не знал о своем родителе Order? Но тогда мне все время нужно будет таскать за собой отдельно Order.

непонятно что должно быть в ордерроу и в ордере и зачем вообще ордерроу, но из ордерроу ордер надо выпилить)

скороговорка

table order_t [ order_num (из Order) , .. (прочие данные из OrderRow)] прочие данные из Order, может быть?

непонятно что должно быть в ордерроу и в ордере и зачем вообще ордерроу, но из ордерроу ордер надо выпилить)

В OrderRow может быть например информация о закзаном продукте и много всего другого. Это просто класс, который описывает одну строку закза. А в Order хранит номер заказа, дату создания, автора документа и т.д. т.е. данные о документе в целом.

В OrderRow может быть например информация о закзаном продукте и много всего другого. Это просто класс, который описывает одну строку закза. А в Order хранит номер заказа, дату создания, автора документа и т.д. т.е. данные о документе в целом.

а в бизнес логике встречается точка входа через ордерроу или все идет в любом случае черещ ордер?

table order_t [ order_num (из Order) , .. (прочие данные из OrderRow)] прочие данные из Order, может быть?

Могут, но как праивло из Order достаточно взять только номер заказаза. Грубо говоря в SQL есть две таблицы order_h (описывает заголовок заказа: автора, дату создания, номер заказа) и order_t (описывает тело заказа: код продукта, кол-во, цена, номера заказа)

Order -> order_h, OrderRow -> order_t и связь между ними через номер заказа ( order_num)?

Order -> order_h, OrderRow -> order_t и связь между ними через номер заказа ( order_num)?

Верно. Поэтому мне удобно держать в OrderRow ссылку на объект Order, что бы при написании логики я понимал к какому заказу относится данная строка.

Могут, но как праивло из Order достаточно взять только номер заказаза. Грубо говоря в SQL есть две таблицы order_h (описывает заголовок заказа: автора, дату создания, номер заказа) и order_t (описывает тело заказа: код продукта, кол-во, цена, номера заказа)

а не проще по внешнему ключу и заджойнить

в ордере onetomany

в ордерроу onetoone

если связь из ордерроу действительно необходима

С БД работа через ORM идет?

но мн кажется что связь от ордерароу излишняя, потому как всеравно все упирается в ордер

С БД работа через ORM идет?

Нет, обычные запросы

Нет, обычные запросы

O_O

))

А как часто из OrderRow используется Order?

а зачем вообще ордерроу использовать без ордера?)

Наверное, просто в таблице показывать список. А при проваливании внутрь инфу об ордер показывать..

Наверное, просто в таблице показывать список. А при проваливании внутрь инфу об ордер показывать..

ну у него же основная инфа в ордере, обычно показывают как раз инфу, а потом списком заказы, тобишь от ордера всеравно не уйти

Ну например в Android делаю форму которая отображает стоки заказа. Логично что каждая строка это экземпляр класса OrderRow. Если пользователь выбирает какую-то строку я отправляю этот экземпляр в форму для детального разворота. Т.е. по сути форма будет работать с OrderRow

ну вот)

Проблема в том, что если пользователь на форме детального разворота что-то поменяет, мне нужно это зафиксировать в БД и тут-то мне точно нужен номер заказа.

ну так может просто order_num держать в OrderRow?

у скалы же с обратной совместимостью не очень

старое заблуждение сейчас более-менее ок, спохватились

Тоже вариант. Но теряется гибкость. Если перед сохранение мне нужно будет выдать сообщение типа: "Вы точно хотите сохранить изменения в документе XXXXXX от XX.YY.ZZZZ" я уже не смогу вывести дату, т.к. я знаю только номер

А так если бы у меня был объект order, нет ограничений.

Надо логику работы смотреть, мне кажется.. Если юзер не на все строки открывает развернутую форму и что-то там не меняет, то можно отдельно доставать только те поля, которые в таблице. При открытии формы запрашивать полные данные.