ну, это не выглядит удобным для использования в коде

Тут сложно сказать, что это за проект. Это мои реальные проекты, которые я использую в своих бизнес процессах. Но это не проекты для людей, это боты. Которые что-то парсят и взаимодействуют со сторонними системами.

Я пишу много разных проектов, которые довольно однотипны.  И в моих проектах намного важнее скорость разработки, чем их надежность и качество (такие вот условия бизнес задач).  И мне постоянно надо работать с состояниями систем.

Например состояние системы может выглядеть примерно так (реальный пример написать не могу, так как NDA).

app_state = {
“processed_block_for_task1”: 123123123,
“processed_block_for_task2”: 123123121,
“last_checked_task1_at”: 2019-10-10 10:10:10,
“last_checked_task2_at”: 2019-10-10 10:10:10,
“was_action1”: True,
“was_action2”: True,
“locked_objects1” : [1,2,3,4,5,6,7],
“best_situations”: [{“param1”: 1, “param2”: Decimal(“123,123”}, {“param1”: 1, “param2”: Decimal(“123,123”}],
}

— т.е. большинство состояний это простые типы (str, int, float, bool, Decimal, datetime), но иногда встречаются и композитные типы: list и dict

И вот я хочу написать для себя реюзабельное django приложение, которое бы содержало бы в себе этот функционал, чтобы в каждом новом проекте мне не надо было бы писать очень похожий код.

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

1) Вначале в settings.py я регистрирую те объекты, которые я хочу использовать в проекте. Я их называю “dinamic values” -> DVALUE
DVALUE = {….}

2) Дальше в самом коде проекта я хочу использовать их максимально удобно, например:

from sharedapp import dvalue

if dvalue.was_action1:
  dvalue.locked_objects += [1]
  …

— это делается так, что в sharedapp я определяю объект dvalue, который определяет getattr и setattr, в через эти методы идет работа с БД данных. + там используется кеш, чтобы не нагружать БД.

3) Все эти состояния должны записываться в БД, так как приложение должно иметь возможность продолжить работу в случае краша сервера, через ребут оного.

4) Еще эти состояния должен иметь возможность отредактировать оператор (человек) этих приложений через браузер, поэтому просто pickle сериализация мне не подходит. И админка этого будет находиться в этом джанговском реюзабельном sharedapp, т.е. мне не придется постоянно в новых проектах писать простой код для редактирования этих состояний.

5) Еще хочется вынести работу с этими dvalue в отдельное реюзаемое приложение, так как там не все банально. И не хочется в каждом новом проекте повторять код. Там нунжны локи, так как есть многопоточность. Еще не должна быть тупо долбежка в БД, т.е. если данные не изменялись, не надо лезть в базу, а надо взять из кеша. Ну и еще не все эти DVALUE должны писаться в БД, часть из них не проблема если потеряется при рестарте сервера.

Вообще в мире джанги есть что-то похожее, называется django-constance. Но только мне нужен более широкий спектр поддержки используемых типов ( а именно композитные), + мне надо для некоторых параметров указывать, что мы их держим только в памяти,  а не записываем в базу.

И я хочу иметь возможсть в БД хранить такие строки данные:

key= processed_block_for_task1, value = 123123123,
key = locked_objects1, value = [1,2,3,4,5,6,7],
key = best_situations, value=  [{“param1”: 1, “param2”: Decimal(“123,123”}, {“param1”: 1, “param2”: Decimal(“123,123”}]

1. Мне кажется, вам не нужен Django.
2. Возможно, вам не нужна реляционная СУБД, т.к. вы не используете её как реляционную. Попробуйте Mongo, мне кажется, под ваши кейсы он больше подойдет.

Кто-то предложил MongoDB и это не я. Мне пришлось сильно сдерживаться:)

Даже такая крутая вещь, как РСУБД имеет границы применимости.

Я раньше как раз и работал с flask + mongo.

Если рассматривать каждый проект как отдельный кусок кода, то я согласен, это реально проще и удобнее.

Но у меня реально все мои проекты они используют много одинакового функционала. Эта фича с dvalue — это всего лишь один пример общего функционала. У меня уже написан реюзабельный django app, который имеет примерно 5 разных фукнциоалов, которые используются во всем моих проектиках.

Я и проникся сейчас django тем, что в нем реально удобно сделать один реюзабельный django app, который можно хранить в отдельном репозитории, и потом использовать во всех проектах.

И с монги (обожаю монгу) я перешел на постгрис из-за того, что хочу иметь возможность адекватной миграции БД. Т.е. у меня в моем реюзабельном джанга аппе есть штук 5 таблиц в БД, и я хочу иметь возможность делать миграции уже в своих многочисленных проектах.

Коллеги, привет! Кто-нибудь писал на Python panflute-фильтры для Pandoc?

А вы не знаете, кто по скорости быстрее в сериализации / десериализации? PyYML или pickle?

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

Реюзабельность можно и без django сделать, он тут ни к чему. Миграции можно написать руками, если это необходимо. Но, насколько я понял ваши задачи, у вас не будет долгоживущих данных. Если есть структурированные, долгоживущие данные - то можно их положить в Postgres и делать миграции с помощью Alembic. А всякие временные состояния и прочее - хранить в Mongo.

Вы определенно усложняете все. Ваши задачи 100% не уникальны, решения уже давно придуманы. Более того, уверен, что их легко можно найти где-нибудь на stackoverflow (это я не к тому, что посылаю вас в гугл, а к тому, что изучение чужого опыта и проектирование тут будут полезнее, чем случайно взятые инструменты).

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

ну я уже посмотрел на исходники django-constance и django-picklefield.

И проблема у меня только в том, как мне сделать админку для опретора, который смог бы руками отредактировать композиционный объект. + Я еще не уверен, как мне быть с полями типа Decimal, так как они точно мне нужны.

Изобретать велосипеды я не хочу, я уже смотрел что есть хорошего на https://djangopackages.org/

django-constance - жутчайший костыль

А вы не знаете, как у PostgreSQL сделан JSONB. Там случаем не расширение какие-нить json-а, вдруг тупа можно класть типы datetime и Decimal?

И то и другое легко сериализовать, но вы должны знать, какой тип данных по какому ключу лежит. Т.е. не получится однозначно замапить эти типы на типы json.

вот поэтому и pickle скорее всего надо использовать. А чтобы отредактировать питонячие данные оператору — тут можно PyYAML как временная прослойка

У вас проблема в архитектуре, увы. Не думаю, что я смогу еще чем-то здесь помочь. Но, скорее всего, вы через некоторое время сами к этому придете.

Чем вам не нравится возмость в коде проекта быстро написать что-то такое:

from sharedapp import dvalue

# other code

if dvalue.was_action1: # тут я читаю из кешированного объекта данные
  # other code
  dvalue.locked_objects += [1] # тут я сохраняю что-то в БД нужное мне


Реюзабельное джано приложение мне дает возможсть:
1) Не надо для этих данных писать отдельную модель
2) Не надо для этих данных заморачиваться с кешированием
3) Не надо для этих данных писать админку

Я согласен, что если вы в своих бизнес реалиях пишите 1-3 проекта годами, то да. Все реюзабельные штуки я и сам не люблю. Но в моих бизнес задачах я каждую неделю делаю по одному джанго проекту, и я не хочу постоянно писать один и тот же код.

Для этого не нужен django. Админка - это, конечно, киллер-фича, т.к. разработка админки - довольно дорогое удовольствие. Но не стоит становиться заложником этой фичи.

Именно джанговской админкой я не пользуюсь уже. У меня даже везде удален admin.py. Какое-то время я помучался, пытался в нее запихивать кучу своего кастомного функционала, а потом понял, что для меня оно зло.

У меня все проекты — они не для людей, там нет клиенсткой части с контеном. Они все из себя состоят только из одного интерфейса для опетатора, это я и называю админкой приложения (которая на самом деле работает с другими внешними системами).

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

Т.е. я могу в репозитории этого реюзабельного приложения исправить ошибки, написать новый код, написать миграции для БД. Потом во всех джанговских приложениях просто обновить версию этой аппы, и все хорошо продолжает работать с новыми возможностями этого общего приложения.