Пользовательские конструкторы для моделей в Google App Engine (python) - PullRequest
4 голосов
/ 30 мая 2010

Я возвращаюсь к программированию для Google App Engine и обнаружил в старом неиспользуемом коде примеры, в которых я писал конструкторы для моделей. Это кажется хорошей идеей, но о ней нет упоминания в Интернете, и я не могу проверить, работает ли она. Вот надуманный пример, без проверки ошибок и т. Д.:

class Dog(db.Model):
    name = db.StringProperty(required=True)
    breeds = db.StringListProperty()
    age = db.IntegerProperty(default=0)

    def __init__(self, name, breed_list, **kwargs):
        db.Model.__init__(**kwargs)
        self.name = name
        self.breeds = breed_list.split()

rufus = Dog('Rufus', 'spaniel terrier labrador')
rufus.put()

** kwargs передаются конструктору Model , если модель построена с указанным parent или key_name, или если указаны другие свойства (например, age) , Этот конструктор отличается от заданного по умолчанию тем, что требует , чтобы были указаны name и breed_list (хотя он не может гарантировать, что они являются строками), и он анализирует breed_list что конструктор по умолчанию не может.

Является ли это допустимой формой создания экземпляров, или я должен просто использовать функции или методы static / class? И если это работает, почему пользовательские конструкторы не используются чаще?

Ответы [ 2 ]

2 голосов
/ 31 мая 2010

В вашем примере, почему бы не использовать синтаксис по умолчанию вместо пользовательского конструктора:

rufus = Dog( name='Rufus', breeds=['spaniel','terrier','labrador'] )

Ваша версия делает его менее понятным семантически ИМХО.

Что касается переопределения конструкторов моделей, Google рекомендует против этого (см., Например: http://groups.google.com/group/google-appengine/browse_thread/thread/9a651f6f58875bfe/111b975da1b4b4db?lnk=gst&q=python+constructors#111b975da1b4b4db), и поэтому мы не видим его в коде Google. Я думаю, что это неудачно, потому что переопределение конструктора может быть полезно в некоторых случаях, например, создание временного свойства.

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

1 голос
/ 30 мая 2010

Обычно нет необходимости делать что-то подобное; конструктор по умолчанию назначит name, и при работе со списком почти всегда имеет смысл передавать реальный список вместо строки, разделенной пробелом (просто представьте себе удовольствие, если вы передали «кокер-спаниель» вместо просто «спаниель» "там, с одной стороны ...).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...