Языки со строгой типизацией следят за контрактом при компиляции кода. Тут скорее всего вопрос касается больше корректности поведения. Например аналогичные исключения кидаются в аналогичных условиях.
А зачем тут транзакция? Активность пользователя можно проверить до того как начать что-то делать. В транзакцию по идее нужно заворачивать код который меняет данные сразу в нескольких сущностях. Если вообще весь код завернуть в транзакцию со всеми проверка, то это может привести к тому что относительно долгое время жизни открытой транзакции в высоконагруженной системе приведёт к быстрому росту лога транзакции и к замедление всех операций в БД.
Вот интересно, можно ли сюда прикрутить двойную буферизацию. Т.е. рисуешь на одном div невидимой, потом включаешь ему видимость, и рисуешь на втором. В следующем кадре они меняются местами. По идее гладкость анимации должна стать повыше.
Если этому решению не нужна исходная таблица для работы после того как обучение закончено, то он её должен условно запомнить.
Ну или тут смысл в том, что это решение работает как планировщик запросов в Sql? Т.е. на декларативный запрос на выборку данных оно создаёт условный план выполнения запроса, который потом выполняется над исходной таблицей. И обучение заключается в том, что сеть условно учиться пользоваться конкретной таблицей . Т.е. без исходной таблицы ответа на запрос не будет.
В последнем варианте не описано где должен находиться класс BeanInitMethodImpl.
В том же пакете что DemoApplication и или иметь какую-то аннотацию? Не ясно как Spring будет искать метод (по имени) который нужно выполнить и что будет если несколько классов будут иметь метод с таким именем. Будет ли вызвано исключение, если среди найденных по имени методов часть будут иметь входные параметры или тип выходного значения отличный от void. Ну или все неподходящий по сигнатуре методы проигнорируются.
Ещё интересный момент, если метод будет бросать проверяемое исключение, он сможет бы использован на предзагрузке?
Можно взять дамп проделать с ним все нужные манипуляции, т.к. без нагрузки, то это вообще не вопрос. Далее поднять новый инстанс сервиса, который будет смотреть на это дамп, а дельту по данным постепенно перегнать со старого прода на дамп, который теперь есть новый прод.
Так и схема на сервере обновиться и сервис, который на новую схему заточен не рухнет, и старый сервис со старой версией БД спокойно доработает.
Мне кажется самое сложное для ИИ это работа по саппорту легаси-кода. С нуля что-то написать не так сложно, как вникнуть в работающую систему на которую не всегда есть дока и что-то там доработать или ошибку поправить. Тут нужно анализировать и код системы и требования заказчика, т.е. это не шаблона я работа с кодом.
Ну тут и не нужна мгновенная реакция, минуты и десятки минут, потому что пики могут периодически повторяться, а поднимать и тушить контейнер это тоже время.
Ну и мы тут не любой гипотетисчкий кейс смотрим, а кейс с читаем из kafka. Совсем универсальное решения, оптимального по всем параметрам для всех вариантов использования понятное дело нет.
Тут вопрос умного devops. Не нужно всегда держать рабочими много контейнеров, при уменьшении нагрузки можно лишние потушить.
Например, если количество не обработанных сообщений в топике стало падать на какой-то процент в единицу времени, значит пик нагрузки прошёл и можно освобождать ресурсы.
Поясните плиз, как отсекается циклы типа
муха-муза-муха
Вроде по коду нет проверки что слово уже есть в маршруте.
А в индексе есть зеркальные элементы:
муха-муза и муза-муха, те теоретически циклы возможны.
Можно немного короче:
плот - клот - клон - слон
Вот так:
плот - слот - слон
Языки со строгой типизацией следят за контрактом при компиляции кода. Тут скорее всего вопрос касается больше корректности поведения. Например аналогичные исключения кидаются в аналогичных условиях.
А как сейчас решаете задачу с упиранием в базу? По идее решение должно одинаково подходить как к монолиту так и к микросервисам.
Слишком простой пример.
В примере в одной таблице и отделы и сотрудники и ЗП и ФИО в одном поле слитно хранится.
В реальной жизни хранить в одной таблице разные сущности в общем случае не "православно" - есть же нормализации.
Интересно насколько быстрее и проще все это будет для примера, где есть несколько связанных сущностей?
То о чем вы пишите - это просто наложить блокировку на объект на время операции. Зачем тут транзакция?
Ну ведь не обязательно товары и юзеры у вас в одном сервисе живут.
Из метода userRepository.getUser(id)
может улететь rest запрос в другой сервис например и как тут транзакция поможет?
А зачем тут транзакция? Активность пользователя можно проверить до того как начать что-то делать. В транзакцию по идее нужно заворачивать код который меняет данные сразу в нескольких сущностях. Если вообще весь код завернуть в транзакцию со всеми проверка, то это может привести к тому что относительно долгое время жизни открытой транзакции в высоконагруженной системе приведёт к быстрому росту лога транзакции и к замедление всех операций в БД.
Транзакции не единственный способ обеспечить консистентность. Есть например паттерн "сага".
Но ведь транзакции не каждая БД поддерживает и если абстрагироваться об особенностей БД, то в общем случае нужно абстрагироваться и от транзакции.
Разве не так?
Месье знает толк в извращения :)
Вот интересно, можно ли сюда прикрутить двойную буферизацию. Т.е. рисуешь на одном div невидимой, потом включаешь ему видимость, и рисуешь на втором. В следующем кадре они меняются местами. По идее гладкость анимации должна стать повыше.
Не совсем понятно как это работает.
Если этому решению не нужна исходная таблица для работы после того как обучение закончено, то он её должен условно запомнить.
Ну или тут смысл в том, что это решение работает как планировщик запросов в Sql? Т.е. на декларативный запрос на выборку данных оно создаёт условный план выполнения запроса, который потом выполняется над исходной таблицей. И обучение заключается в том, что сеть условно учиться пользоваться конкретной таблицей . Т.е. без исходной таблицы ответа на запрос не будет.
Т. е. тут по сути модель запоминает таблицу? Т.е. если в таблицу добавить новые строки, то нужно будет заново обучать модель?
Зачем нужен медленный вариант если есть быстрый? И почему AWS не может автоматом заграалить код?
Вопросы риторический, но это было бы удобнее для конечных потребителей.
Ну нужно выйти из зоны комфорта встать уже и включить музыку ?.
Сейчас по факту многим наоборот не хватает движения.
Да, я это все прочитал. Вопрос, что будет если нарушить правила :)
Просто упадет с ошибкой, просто проигнорирует неподходящие методы, выдаст при старте в лог диагностику или еще что-то.
В последнем варианте не описано где должен находиться класс BeanInitMethodImpl.
В том же пакете что DemoApplication и или иметь какую-то аннотацию? Не ясно как Spring будет искать метод (по имени) который нужно выполнить и что будет если несколько классов будут иметь метод с таким именем. Будет ли вызвано исключение, если среди найденных по имени методов часть будут иметь входные параметры или тип выходного значения отличный от void. Ну или все неподходящий по сигнатуре методы проигнорируются.
Ещё интересный момент, если метод будет бросать проверяемое исключение, он сможет бы использован на предзагрузке?
Можно взять дамп проделать с ним все нужные манипуляции, т.к. без нагрузки, то это вообще не вопрос. Далее поднять новый инстанс сервиса, который будет смотреть на это дамп, а дельту по данным постепенно перегнать со старого прода на дамп, который теперь есть новый прод.
Так и схема на сервере обновиться и сервис, который на новую схему заточен не рухнет, и старый сервис со старой версией БД спокойно доработает.
Мне кажется самое сложное для ИИ это работа по саппорту легаси-кода. С нуля что-то написать не так сложно, как вникнуть в работающую систему на которую не всегда есть дока и что-то там доработать или ошибку поправить. Тут нужно анализировать и код системы и требования заказчика, т.е. это не шаблона я работа с кодом.
Ну тут и не нужна мгновенная реакция, минуты и десятки минут, потому что пики могут периодически повторяться, а поднимать и тушить контейнер это тоже время.
Ну и мы тут не любой гипотетисчкий кейс смотрим, а кейс с читаем из kafka. Совсем универсальное решения, оптимального по всем параметрам для всех вариантов использования понятное дело нет.
Тут вопрос умного devops. Не нужно всегда держать рабочими много контейнеров, при уменьшении нагрузки можно лишние потушить.
Например, если количество не обработанных сообщений в топике стало падать на какой-то процент в единицу времени, значит пик нагрузки прошёл и можно освобождать ресурсы.