Прошу меня извинить, не сразу уяснил вопрос. Ваше решение больше уже архитектурное (nginx+gunicorn), мне же хотелось решить только инструментом Python.
Но благодаря Вам у меня возникло желание исследовать ещё и архитектурные варианты, может даже вторую часть напишу, как минимум уже два варианта имеется)
В celery тоже можно одним воркером обойтись, и тоже им в базу писать.
А вот асинхронный таск... Хм..
Всё равно запись будет последовательной (на уровне базы блок, пишем же наверно в одну таблицу) и хронология может сбиться. При асинхронном воркере и асинхронной записи в базу, очередь конечно быстрее будет разбираться, но будут ли производители так быстро публиковать события, судя по бизнес-процессам - нет.
Думаю асинхронность здесь избыточна, хотя и самому нравится использовать asyncio. Ну что поделаешь, модно)
Интересует как раз использование Alembic (а других вроде как и нет) на проде.
Поясню, в одном из своих проектов как раз думал использовать связку SQLAlchemy — Alembic, но после прототипа от последнего решил оказаться, а изменения в модели реализовать самостоятельно средствами той же SQLAlchemy.
В чем причина использования именно такой модели электрического счетчика?
Предпочтительнее использовать счетчик с RS-485, наличие журнала ПКЭ также будет не лишним.
Не рассматривали вариант постоянного опроса счетчика, без установления канала связи во время звонка?
Функционал востребован, положительно впечатлила архитектура аппаратного средства и его размеры. Правда выложить 15 т.р. за устройство пока не готов, поэтому считаю правильным ориентирование на работу с авто дилерами и с авто производителями.
И да, соглашусь с
Хорошо бы увидеть коды на github.
Как бы потом не оказалось, что моей машиной через беспроводной канал другой дядя будет управлять.
Для проектов нормативных правовых актов подготовленных федеральными органами исполнительной власти такой механизм уже применяется, причем этот механизм обязателен.
Прошу меня извинить, не сразу уяснил вопрос. Ваше решение больше уже архитектурное (nginx+gunicorn), мне же хотелось решить только инструментом Python.
Но благодаря Вам у меня возникло желание исследовать ещё и архитектурные варианты, может даже вторую часть напишу, как минимум уже два варианта имеется)
Это бы уже был не XML-RPC, значит, помимо все прочего, пришлось бы переписывать еще и клиентов. Такой вариант был не желателен.
В celery тоже можно одним воркером обойтись, и тоже им в базу писать.
А вот асинхронный таск... Хм..
Всё равно запись будет последовательной (на уровне базы блок, пишем же наверно в одну таблицу) и хронология может сбиться. При асинхронном воркере и асинхронной записи в базу, очередь конечно быстрее будет разбираться, но будут ли производители так быстро публиковать события, судя по бизнес-процессам - нет.
Думаю асинхронность здесь избыточна, хотя и самому нравится использовать asyncio. Ну что поделаешь, модно)
Спасибо. Пишите еще, будет интересно прочитать статью о сборе данных.
Столько недовольных комментариев, ну порадуйтесь вы за сотрудников указанных в статье компаний. Им, наверно, приятно упоминания их компаний здесь...
Поясню, в одном из своих проектов как раз думал использовать связку SQLAlchemy — Alembic, но после прототипа от последнего решил оказаться, а изменения в модели реализовать самостоятельно средствами той же SQLAlchemy.
А как в Вашем случае Вы решаете вопрос с изменениями в модели данных во время жизненного цикла ПО?
Предпочтительнее использовать счетчик с RS-485, наличие журнала ПКЭ также будет не лишним.
И да, соглашусь с Вопрос безопасности слабо раскрыт.
Тоже подумываю к своему счетчику подключится, только у меня Микрон, но протокол похож.