#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. вы можете предсказать существование наследника динамически на основе сгенерированного кода, хранящегося в базе данных. таким образом, ваш код никогда не сломается, если у вас там нет файлов