Existing options for representing a Contact:
1a) Contact entity w/ ListProperty's: addresses, emails, etc.
1b) Contact entity w/ address1, address2, address3, email1, email2, email3, etc. properties.
2a) Contact entity w/ addresses property listing keys of Address entities. This is a workaround because lists of ReferenceProperty is unsupported.
I think it would be useful to have lightweight entities which can be embedded in the classic entities. This would enable more options for Contact:
2b) Contact entity w/ addresses property listing NestedReferenceProperty referencing Address nested entities.
2c) Contact entity containing Address nested entities--query by ancestor.
Protocol buffers support nesting & repeating but not arbitrary graphs. Therefore, an implementation based on protocol buffers would restrict expressiveness or face that challenge.
Possible API additions:
- constructor: new Model(nest=parent)
- property type: NestedReferenceProperty; supported in lists.
- custom index support.
are you sure everything is indexed?
ReplyDeleteThe reason I ask is that in the appaengine you need to upload the JDO query patterns. What is the point for that if everything indexed?(mulit column indexes?)
But if you have stuff you do not want to index... throw it into the blobstore.