Для работы SqlAlchemyOutboxedEventRepository требуется SQLAlchemy сессия. В примере показано, что в хендлере команды вызывается self.outbox.add() и затем await self.outbox.commit(). Предполагается, что эта же сессия используется и для сохранения бизнес-агрегатов в базу данных?
Как фреймворк заставляет или помогает разработчику использовать одну и ту же сессию и одну транзакцию для сохранения и агрегата, и записи в Outbox? В примере кода хендлера этого не видно. Если разработчик случайно создаст две разные сессии или не обернет вызовы в единую транзакцию, то паттерн Transactional Outbox сломается (возможна ситуация: бизнес-данные сохранены, а запись в Outbox — нет, или наоборот).
Какие инструменты предоставляет фреймворк для внедрения зависимости (OutboxedEventRepository), чтобы она была привязана к scope запроса и всегда использовала ту же сессию, что и репозиторий агрегата? В README упоминается di контейнер и scope="request", но нет примеров или проверок, гарантирующих, что оба репозитория получат один и тот же объект сессии.
Есть два алгоритма работы, speed-based и torque-based. Первый - у вас таблица с переключениями есть, второй - исходя из нагрузки на двигатель и опорных данных таблицы скоростей
Спасибо за ваши рекомендации! Я, действительно, не ожидал такого ажиотажа на свою поделку.
Как вы верно заметили - у меня очень ранний прототип. Я прекрасно понимаю, что для промышленной коммерческой реализации необходимо будет разрабатывать\дорабатывать блок до серийного качества со всеми вытекающими стандартами и требованиями.
Цель поста - получить контакты специалистов, готовых помочь с теорией и ткнуть носом куда надо.
Я на текущий момент только занимаюсь изучением правильного проектирования схем и тестирую гипотезы. Как на столе так и в ближайшем будущем, на полигоне.
С KiCad начал работать только 2 недели как. Параллельно осваивая для себя О дивный чудный мир МК. Пытаюсь после работы с пользой тратить время в области, которая нравится. Весь мой опыт и навыки схемотехники - это 1 курс универа)
Мне еще многое предстоит изучить, выяснить и освоить.
Существует проект ECU Speeduino. Для TCU подобных нет. В любом случае, я пока поддерживать собираюсь свой проект и реализовывать свои идеи. Будет он коммерчески и\или идейно успешный - покажет время. Но кто ничего не делает - у того точно ничего не получится.
Скажу больше - на текущий момент я аппаратную часть планирую сделать OpenSource, а самому заняться именно тем, что получается лучше всего - программной составляющей. Данный пост больше связан с поиском единомышленников, энтузиастов по теме и крутых спецов, которые могут посоветовать свои идеи.
Если честно, я этим проектом занимаюсь только месяц, и то по вечерам после работы. Идея проекта возникла - чуть больше года назад. До многого я еще или не додумался или банально не знал.
До этого делал исключительно примитивные схемы. Изучал по аналогии с Ratcu все, методом реверс инжиниринга платы по фото.
За сегодня в комментариях я получил больше информации, советов и пользы, чем мог бы себе представить. Не ожидал такого ажиотажа по теме.
Если не составит труда найти схему питания, которую вы считаете достойной - буду благодарен, если поделитесь, я узучу. Это пет проект, у меня 2 недели опыта работы в KiCad. Аппаратную часть я планирую сделать OpenSource, по аналогии с Speeduino.
Горжусь своими студентами! Никита К., молодец!
Вопрос возник небольшой.
Для работы SqlAlchemyOutboxedEventRepository требуется SQLAlchemy сессия. В примере показано, что в хендлере команды вызывается self.outbox.add() и затем await self.outbox.commit(). Предполагается, что эта же сессия используется и для сохранения бизнес-агрегатов в базу данных?
Как фреймворк заставляет или помогает разработчику использовать одну и ту же сессию и одну транзакцию для сохранения и агрегата, и записи в Outbox? В примере кода хендлера этого не видно. Если разработчик случайно создаст две разные сессии или не обернет вызовы в единую транзакцию, то паттерн Transactional Outbox сломается (возможна ситуация: бизнес-данные сохранены, а запись в Outbox — нет, или наоборот).
Какие инструменты предоставляет фреймворк для внедрения зависимости (OutboxedEventRepository), чтобы она была привязана к scope запроса и всегда использовала ту же сессию, что и репозиторий агрегата? В README упоминается di контейнер и scope="request", но нет примеров или проверок, гарантирующих, что оба репозитория получат один и тот же объект сессии.
Я мат.модель делаю, как закончу - выпущу отдельную статью на эту тему
Есть два алгоритма работы, speed-based и torque-based. Первый - у вас таблица с переключениями есть, второй - исходя из нагрузки на двигатель и опорных данных таблицы скоростей
Эта разработка - попытки применить навыки и знания на практике, воспринимайте это в таком ключе)
Начну со второго
Я интерфейс стянул у настроек Ратку и не все подключил еще.
По первому вопросу - два варианта сейчас есть. По ДАД, или Дросселю определять. Пока еще думаю как лучше, копаю в алгоритмы управления.
Вот тут, luatos core esp32c3. Его модели в 3д нет, поэтому на превью я никак его показать не могу.
ТС требует статью! ))
Был бы очень благодарен за такую информацию, на самом деле.
Спасибо!
Здравствуйте! Дисплей и возможность ручного управления реализованы
Спасибо за ваши рекомендации! Я, действительно, не ожидал такого ажиотажа на свою поделку.
Как вы верно заметили - у меня очень ранний прототип. Я прекрасно понимаю, что для промышленной коммерческой реализации необходимо будет разрабатывать\дорабатывать блок до серийного качества со всеми вытекающими стандартами и требованиями.
Цель поста - получить контакты специалистов, готовых помочь с теорией и ткнуть носом куда надо.
Я на текущий момент только занимаюсь изучением правильного проектирования схем и тестирую гипотезы. Как на столе так и в ближайшем будущем, на полигоне.
С KiCad начал работать только 2 недели как. Параллельно осваивая для себя О дивный чудный мир МК. Пытаюсь после работы с пользой тратить время в области, которая нравится. Весь мой опыт и навыки схемотехники - это 1 курс универа)
Мне еще многое предстоит изучить, выяснить и освоить.
Существует проект ECU Speeduino. Для TCU подобных нет.
В любом случае, я пока поддерживать собираюсь свой проект и реализовывать свои идеи. Будет он коммерчески и\или идейно успешный - покажет время. Но кто ничего не делает - у того точно ничего не получится.
Разумеется, голову всегда нужно держать включенной :)
Скажу больше - на текущий момент я аппаратную часть планирую сделать OpenSource, а самому заняться именно тем, что получается лучше всего - программной составляющей.
Данный пост больше связан с поиском единомышленников, энтузиастов по теме и крутых спецов, которые могут посоветовать свои идеи.
Если честно, я этим проектом занимаюсь только месяц, и то по вечерам после работы. Идея проекта возникла - чуть больше года назад.
До многого я еще или не додумался или банально не знал.
До этого делал исключительно примитивные схемы. Изучал по аналогии с Ratcu все, методом реверс инжиниринга платы по фото.
За сегодня в комментариях я получил больше информации, советов и пользы, чем мог бы себе представить. Не ожидал такого ажиотажа по теме.
Спасибо! Изучу
Спасибо. Мне неоднократно на это указали, изучу вопрос.
Если не составит труда найти схему питания, которую вы считаете достойной - буду благодарен, если поделитесь, я узучу. Это пет проект, у меня 2 недели опыта работы в KiCad. Аппаратную часть я планирую сделать OpenSource, по аналогии с Speeduino.
7mgteu
Вот это забавно, надо покурить ГОСТы, спасибо за вектор
Интересно, я о таком не слышал. Не могли бы вы прислать примеры или ссылки на такого рода статьи?