Tim put this much better than my short description.  I was trying to
oversimplify for brevity, and Tim gave a very concise answer that handled it
much better.  

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Tim
Sent: Wednesday, May 18, 2011 9:32 AM
To: [email protected]
Subject: [google-appengine] Re: Is the order of datastore puts guaranteed?

 

Actually sophisticated banking systems use append only datastores and
bi-temporal timestamps, whereby you record when an event actually occurred
and when we found out about the event occurring. 

 

This way, when we only get told at 12:15 that you took $200 out of an ATM at
12:05, we simply append this info to the event log and can do sophisticated
things later such as realise that as of 12:06, you had withdrawn cash, but
when we checked your balance for an automated payment at 12:10, it APPEARED
that you had the funds to cover it. That is, we can spot the difference
between what we thought your balance was at the time, and what we now think
it was at the time.

 

It means we don't actually store "your current balance" because the concept
is not precise enough, but we can tell you at any time what we think your
current balance is. And because the datastore is append only, we avoid all
sorts of transactional bottlenecks, and keep a much more accurate audit
trail that includes being able to work out things like "we erroneously
charged you for a service at time T1, and refunded the charge at time T2 to
be effective from time T1 - between T1 and T2 we thought your balance was
less and therefore charged you overdraft fees, but we can now see that you
weren't overdrawn during those times, so we should also append an event that
indicates that we now recognise the overdraft fee shouldn't have charged".

 

This sort of bitemporal store is very handy for getting rid of all sorts of
event ordering and transactional deadlock complexities, but it does tend to
mean that some queries can take a bit more legwork :)

 

If you're doing lots of writes, and relatively fewer reads, and given the
performance profile of the datastore, it MAY be worthwhile for looking at
such an approach for some people.

 

http://en.wikipedia.org/wiki/Temporal_database

 

-- 
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.

Reply via email to