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

[danilovmy]

чет много что недоделано, для такой маленькой библиотеки:

1. Сериализатор строки конфига сохраняет объект, а HistoryEvent не пишет.

2. Менеждмент команда для строки конфига сохраняет объект, а HistoryEvent не пишет

3. А если пишет, потому как где-то висит сигнал post_save (я не нашел), то в админке он делает это дважды.

4. HistoryEvent повторяет модель django_admin_log, почему не использовали ее, поскольку фактически сейчас у вас две таблицы django_admin_log и liveconfigs_historyevent содержат одну и ту же информацию.

5. Ставить DRF только для одного ViewSet это непонятно. Чем не устроил простой GCBV?

6. Удаление конфигов вместо действия администратора в менеджменте. Это за пределами моего понимания. Т.е. в админке создать можно, удалить можно, а вот "Удалить конфиги, которые есть в БД, но нет в коде'" - это можно только через командную строку. Мне кажется это странным.

В итоге, по реализации вы все же остановились на создать и проинициализировать объект Django, я про инстанс класса ConfigRow. Поскольку, без инстанса данных вы не получите. Но потом:

Непонятно, как такое использовать. Инстанцировать класс? Обращаться к атрибуту класса, например UseNewFeature.value? Выглядит не очень красиво.

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

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

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

@jandor В любом случае спасибо, критиковать, как я, каждый может, а вот проект опубликовать и статью о нем написать - это редкость!

[jandor]

Привет и спасибо за коммент и замечания :) Наконец-то могу ответить.

Сериализатор строки конфига сохраняет объект, а HistoryEvent не

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

Менеждмент команда для строки конфига сохраняет объект, а HistoryEvent не пишет

Да, действительно. Это тоже починим.

А если пишет, потому как где-то висит сигнал post_save (я не нашел), то в админке он делает это дважды.

Нашел это место, тоже проверим :)

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

Мы в какой-то момент отказались от LogEntry в пользу своей таблицы по-моему из-за того, что в родном LogEntry не записывалось старое значение. Но в свою таблицу (я на нее сейчас смотрю) старое значение мы тоже не пишем. Логично будет в LogEntry.change_message записывать дифф между двумя значениями

Ставить DRF только для одного ViewSet это непонятно. Чем не устроил простой GCBV?

Принесли его из основного проекта, не подумали про остальных. Вот, получили обратную связь, спасибо )

Удаление конфигов вместо действия администратора в менеджменте. Это за пределами моего понимания. Т.е. в админке создать можно, удалить можно, а вот "Удалить конфиги, которые есть в БД, но нет в коде'" - это можно только через командную строку. Мне кажется это странным.

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

В итоге, по реализации вы все же остановились на создать и проинициализировать объект Django, я про инстанс класса ConfigRow. Поскольку, без инстанса данных вы не получите.

Непонятно, как такое использовать. Инстанцировать класс? Обращаться к атрибуту класса, например UseNewFeature.value? Выглядит не очень красиво.

Django есть еще класс "AppConfig"

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

class Config(BaseConfig):
  MY_FLAG: bool = False
  MY_VALUE: int = 42

И сразу его используем без инстанцирования

if Config.MY_FLAG:
  print("value is", Config.MY_VALUE)

При выкатке описание MY_FLAG и MY_VALUE ""само" попадет в админку стенда вместе с их описаниями и прочими метаданными из доп. атрибутов, если они есть