Yes I also thought about this when denormalizing. And this could be generalized to a whole model by serializing it into a protobuf StringProperty.
This is probably best for models with infrequent writes, like a User personal information. On Dec 9, 7:06 am, Robert Kluin <robert.kl...@gmail.com> wrote: > Hi Zach, > I think this is a pretty useful idea. It would probably help people > new to app engine design more efficient apps since it would help get > past the typical "you want me to DEnormalize my data? That is a > really really bad sin though, right?" feelings that are common when > someone first suggests the idea. > > I think both methods look super-clean, but I like the idea of > SyncedProperty -- it implies the synced-property will use the type > from the 'source' kind which is cool. An entity might have multiple > references to the same kind, so I guess we would need to specify which > reference property to use and the property to sync from. I am not > sure this could be done within the class definition, since it is not > yet defined. Maybe it could look something like: > > class Story(db.Model): > author_key = db.ReferenceProperty(Author) > title = db.StringProperty() > date = db.DateTimeProperty() > > # Setup the Synced properties... > Story.author_name = db.SyncedProperty(Story.author_key, Author.name) > Story.author_age = db.SyncedProperty(Story.author_key, Author.age) > > What are some cleaner ways to accomplish that? > > I would think the Author kind needs a "revision number" property and > that the Story kind would also then get an implicit > "author_key_revision" property, so that we can ensure old updated > never overwrite new updates. > > Then I guess the trick would be to adjust the Author kind so that when > it is saved a (transactional) task is kicked off to process those > updates. Perhaps db hooks could be used? To ensure consistency, I > believe all writes to the Author entity will need done within a > transaction. > > Robert > > On Wed, Dec 8, 2010 at 15:16, fission6 <zisilver...@gmail.com> wrote: > > I think it could be very powerful to consider the following concept as a way > > to ease data / relational integrity while still maintaing a sense of > > denormalization. > > Often times certain fields for a model may be replicated to maintain a more > > embedded view of properties. This leaves the developer responsible for its > > upkeep often times through db.keys / ReferenceProperties between the model > > and its counterpart (relation). Would it be possible to stream line this by > > specifying that a given field should be synced to a model field; taking > > advantage of the backwards/forward relations maintained by > > ReferenceProperties. > > For example: > > class Author(db.Model): > > author_name = db.StringProperty() > > sex = db.StringProperty() > > birth_day = db.DateTimeProperty() > > ..... > > class Story(db.Model): > > author_key = db.ReferenceProperty(Author) > > author_name = db.StringProperty() > > title = db.StringProperty() > > date = db.DateTimeProperty() > > ..... > > > Here the developer would need to maintain the author_name explicitly > > whenever the referring author's name changes. Although this is not often, > > and serves as a simple example, its often routine to have to maintain some > > sort 'foreign property' in this manor. It would be very powerful and > > encouraging to offer something like the following descriptor for a field > > which can be managed through handler somewhere in the background. Using the > > models above: > > I think it could be very powerful to consider the following concept as a way > > to ease data / relational integrity while still maintaing a sense of > > denormalization. > > Often times certain fields for a model may be replicated to maintain a more > > embedded view of properties. This leaves the developer responsible for its > > upkeep often times through db.keys / ReferenceProperties between the model > > and its counterpart (relation). Would it be possible to stream line this by > > specifying that a given field should be synced to a model field; taking > > advantage of the backwards/forward relations maintained by > > ReferenceProperties. > > For example: > > class Author(db.Model): > > author_name = db.StringProperty() > > sex = db.StringProperty() > > birth_day = db.DateTimeProperty() > > ..... > > class Story(db.Model): > > author_key = db.ReferenceProperty(Author) > > author_name = db.StringProperty(sync=author_key.author_name) > > title = db.StringProperty() > > date = db.DateTimeProperty() > > ..... > > What happens here is that a manager handles the backwards relations for the > > ReferenceProperty so that every time the related Author name changes / its > > synced to its counterpart "foreign fields". I am not sure that > > the (sync=author_key.author_name) is the most ideal way to specify this / > > perhaps just a new Property in general such as > > SyncProperty(some_key.somefield) or ForeignProperty() may be more ideal. > > Regardless, this would be an amazing concept to see within the app engine > > sdk. The point here is that author_name is still embed but managed through > > its related reference in terms of syncing to a value that may change. > > Thanks, > > Zach > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To post to this group, send email to google-appeng...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-appengine+unsubscr...@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
