Nice job encoding the necessary info in keys :)
Is there value in putting the MessageRead entity in the same entity
group as the message?
Not sure but don't think you'd need updates to MessageRead to be
transactional with any updates to Message or other MessageRead
entities for the same message?
Is there value in putting the MessageRead entity in the same entity
group as the message?
Just to do transactional mark as read. I agree in most cases it's
not worth the trouble.
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To post
i too am facing a similar problem, was thinking of a design similar to
yours. anyone have any comments on Chris' design?
On Nov 5, 5:35 pm, Chris cskjoldb...@gmail.com wrote:
Hi All
I'm looking for some input onDb.Modeldesign for the following
scenario:
1) A User can send a message which
An extra write when someone clicks to read a message doesn't seem
massively expensive...at least not from a latency point of view. You
probably would be OK.
However you could optimise these approach further with a write-behind
cache for example.
That could be particularly effective if you expect
There is a better solution to this problem.
You can use a special entity MessageRead with no property and a
key_name= message_id + recipient_id
indexes = keys_only query on MessageIndexes
for k in indexes:
keys.append( k.parent() )
keys.append( db.Key.from_path('MessageRead', k.parent().id()
