Django: расширение моделей других приложений

#python #django #django-models #django-migrations #django-apps

#python #django #django-модели #django-миграции #django-приложения

Вопрос:

Я работаю над небольшим ERP-подобным проектом на Django, который содержит различные приложения (продукты, продажи, покупки, бухгалтерия, MRP, …). У некоторых из них есть зависимости (например, для приложения продаж требуется приложение продуктов).

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

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

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

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

Каков наилучший способ добиться этого? Должен ли я изучать написание пользовательских операций миграции? В противном случае, есть ли лучшие подходы? Спасибо!

Комментарии:

1. Удалось ли вам выполнить то, что вы просили? На самом деле меня интересует ваш метод (если вы его нашли)

Ответ №1:

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

вам даже не нужно иметь абстрактный класс

 my_evaluated_code = 'from ' mymodule_var_name   ' import '   myclass_var_name  ' as custommodule'
eval(my_evaluated_code)
custommodule.common_method()
  

Комментарии:

1. Спасибо, но как именно это поможет добавить новые поля в таблицы существующих приложений?

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