У меня есть интернет-магазин на основе Django, который развивался в течение прошлого года. В настоящее время в одной и той же кодовой базе работает около 8 страновых магазинов, плюс API, и скоро должен появиться сайт B2B, и еще несколько стран добавятся в список.
Необходимы изменения в структуре модели, особенно вокруг полей в моделях адресов, модели счетов и т. Д.
Чтобы усложнить задачу, на сайте работает multidb с каждым экземпляром магазина в отдельной базе данных. Поэтому у меня есть ситуация, когда у меня может быть базовая модель ABC, например:
class Address(models.Model):
class Meta:
abstract=True
class Address_UK(Address):
class Meta:
db_table="shop_address"
class Address_IT(Address):
class Meta:
db_table="shop_address"
[etc]
Затем введите код в приложении, чтобы выбрать правильную модель, например,
if countrysettings.country == "UK":
address = Address_UK()
elif countrysettings.country == "IT":
address = Address_IT()
Countrysettings.country на самом деле является отдельным классом настроек, который подклассами threading.local и кодом страны, который также соответствует ключу в настройках. Базы данных, настраиваются обработчиком промежуточного программного обеспечения геолокации. Таким образом, выбирается правильная база данных, и конкретные отклонения модели отражаются в базе данных каждой страны.
Но у этого подхода есть проблемы:
Он полностью нарушает syncdb и не годится для юга, если только я не взломаю ./manage.py, чтобы я мог передать db страны, вместо того, чтобы требовать промежуточное программное обеспечение для его установки.
Кажется грязным. Так много, если countrysettings.country == "xx": код лежит и так много подклассов.
Так что я думал об использовании django-eav вместо этого, но я предвижу проблемы в админе, и в частности упорядочение полей. Я знаю, что django-eav создаст модель модели для администратора, которая включает поля eav, но в идеале я бы хотел, чтобы они отображались или скрывались в зависимости от страны.
Также я подумал о том, чтобы иметь не абстрактный базовый класс, например Адрес, а затем, при необходимости, создайте специфические для страны варианты (например, наследование таблицы моделей). Но затем я предвижу, что базовые модели будут перегружены полями one2one для каждого варианта модели. Но это решит проблемы с админом.
Другой вариант может состоять в том, чтобы иметь дополнительное поле данных и сериализовать дополнительные поля в json или csv или что-то еще и сохранять их в этом поле.