在 python/google 应用引擎中定义对象/实体的属性
我见过类似这样的重复示例：
from google.appengine.ext import db
import datetime
class Book(db.Expando):
pass
obj = Book()
obj.title = 'The Grapes of Wrath'
obj.author = 'John Steinbeck'
obj.copyright_year = 1939
obj.author_birthdate = datetime.date(1902, 2, 27)
obj.put()
这是我第一次遇到这种代码，其中属性设置在类定义的外部。我认为这是一种非常糟糕的做法。我更喜欢：
class Book(db.Model):
title = db.StringProperty()
author = db.StringProperty()
copyright_year = db.IntegerProperty()
author_birthdate = db.DateProperty()
...
obj = Book(title='The Grapes of Wrath', author='John Steinbeck', copyright_year=1939, author_birthdate=datetime.date(1902, 2, 27))
有人可以对作者实践的性质提供保证吗？这种方法何时何地会被接受？
有人提到，谷歌的数据存储模型具有非同寻常的灵活性。我认为这个例子可能是对该概念的一个糟糕且过于微妙的介绍。作者其实已经指出了这种风格的缺点，却又不断地重复。所以，它可能有一些优势。
I've seen repeated examples like this:
from google.appengine.ext import db
import datetime
class Book(db.Expando):
pass
obj = Book()
obj.title = 'The Grapes of Wrath'
obj.author = 'John Steinbeck'
obj.copyright_year = 1939
obj.author_birthdate = datetime.date(1902, 2, 27)
obj.put()
It's the first time I've come across this sort of code, where the attributes are set outside of the class definition. It strikes me as a very bad practice. I prefer:
class Book(db.Model):
title = db.StringProperty()
author = db.StringProperty()
copyright_year = db.IntegerProperty()
author_birthdate = db.DateProperty()
...
obj = Book(title='The Grapes of Wrath', author='John Steinbeck', copyright_year=1939, author_birthdate=datetime.date(1902, 2, 27))
Can someone offer an assurance over the nature of the author's practice? Where and when such a method would be acceptable?
It was mentioned that google's model for data storage allows for unusual flexibility. I thought this example may be a poor and overly subtle introduction to that concept. The author has actually pointed out the disadvantages of this style, yet goes on to keep repeating it. So, there might be some advantage to it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
此处对此进行了记录。提供的代码片段是有效的，尽管不清楚为什么该类完全是空的（可能用于说明目的）。我想主要问题是何时使用 Expando 模型？
想象一下一个网站可能收集各种商品的订单。一个顾客可能想要订购一只小猫，另一个顾客可能想要订购一本书，等等。一本书和一只小猫几乎没有共同点，也许只是价格和重量。但我们希望我们的客户提供他们的详细信息，例如，一位客户可能会订购一只 3 个月大的小猫，暹罗猫，蓝眼睛，而另一位客户可能会订购《指环王》第二版，精装，作者签名等。属性在收集订单时并不相关，它们对于您的业务逻辑至关重要。您也可以稍后处理这些属性。
这里唯一的解决方案是使用 Expando 模型，因为您无法创建覆盖所有现有属性的通用类（或类层次结构）。 Expando 模型将保存所有常规属性（价格、重量、跟踪 ID、运费、定制费用等）和方法（计算总计、折扣等），其余属性将由客户动态创建在运行时。模型实例将及其所有属性保存到数据存储中，任何特定实例将通过 Model.properties() 方法返回在其上定义的所有属性。
This is documented here. The snippet provided is valid, although it's not clear why the class is completely empty (might be for illustrational purposes). I suppose the main question is when to use Expando Model?
Imagine a site collecting orders for all kinds of goods possible. One customer might want to order a kitten, another one might want to order a book, etc. A books and a kitten have very little in common, maybe just a price and weight. But we want our customers to provide details on their irders, e.g. one customer might order a kitten 3 months old, siamese, blue eyed, and another might order "Lord of The Rings" 2nd edition, hardcover, author signed, etc. Although these properties aren't relevant at the moment of collecting an order, they are vital of your business logic. Also you might process these properties later.
The only solution here is to use Expando model, because you can't create a universal class (or hierarchy of classes) covering all the existing properties. The Expando model will hold all the general properties (price, weight, tracking id, shipping cost, custom fees, etc.) and methods (calculating total, discounts, etc.), the rest of the properties will be created by the customer dynamically at runtime. A model instance will be saved into the datastore with all its properties, and any particular instance will return all the properties defined on it via Model.properties() method.
那很好笑。我读同一本书，也有同样的想法。自从 App Engine Python 推出以来，我一直在使用它，并且从不使用 Expando 模型。
我认为作者的意图是让那些可能不熟悉 Python 类的读者轻松了解定义模型的概念，但我认为这没有帮助。
有一次，当我将模型之一中的字段从使用 DateTime 切换为使用自定义 String 属性时，数据存储区的灵活性对我派上了用场。具有这两种类型字段的实体可以并存，并且我可以在访问每个实体时迁移它们。
That's funny. I read the same book and thought the same thing. I've been using App Engine Python since it launched and NEVER use Expando models.
I think the author's intent was to ease readers who may not be familiar with Python classes into the concept of defining models, but I didn't find it helpful.
One time that the datastore's flexibility came in handy for me was when I switched a field in one of my models from using DateTime to using a custom String property. Entities with fields of both types could live side-by-side, and I could migrate them as each was accessed.