Есть ли недостатки в наследовании от класса db.Expando в AppEngine?

Question

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

class ImgModel(db.Expando):
    height = db.IntegerProperty()
    width = db.IntegerProperty()
    url = db.StringProperty()
    img_data = db.BlobReferenceProperty()

class company(db.Expando):
    logo = db.DenormalizedImgProp(prefix=u'logo')

class DenormalizedImgProp(db.ReferenceProperty):
    denorm_attrs = [u'height', u'width', u'url']

    def __init__(self,prefix,verbose_name,collection_name,**attrs):
        super(DenormalizedImgProp, self).__init__(ImgModel,verbose_name,collection_name,**attrs)
        self.denorm_field_prefix = prefix

    def __set__(self, model_instance, value):
        super(DenormalizedImgProp, self).__set__(model_instance, value)
        for attr in self.denorm_attrs:
            setattr(model_instance, u'%s_%s' %
                (self.denorm_field_prefix, attr),value)

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

Answer 1

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

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

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

Меня беспокоит то, что вам нужно быть осторожным с индексами. Expando позволяет создавать множество динамических свойств, не задумываясь о влиянии на ваши индексы. Чем больше индексов, тем больше времени для записи объектов при изменении значений свойств. Чем больше запросов, требующих сортировки или фильтрации неравенства для нескольких свойств с несколькими значениями, тем легче получить огромные пользовательские индексы. Поскольку вы автоматизируете создание этих динамических свойств, вам нужно будет убедиться, что небольшие изменения кода не взорвут ваши индексы.

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