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 <[email protected]> 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
