Another confusing matter, do we .rollback() explicitly, even if the exception is from the .commit() - I guess so - honestly they all make up a huge code mess, it could've been simpler if the transaction routines were actually transaction routines and these were automated? I guess one could also easily write wrappers that do this
So my point is, I guess it's not a transaction system exactly, but more like a lock, lock-check, lock-release system - correct me if I missed anything On Sunday, January 10, 2021 at 9:12:21 PM UTC+3 Kaan wrote: > The docs here use .run() - more like a .start()-like command: > https://cloud.google.com/datastore/docs/concepts/transactions > > However the direct reference: > https://googleapis.dev/nodejs/datastore/latest/Transaction.html#run > > Uses .run(function(){ DO_THINGS_HERE_THEN_COMMIT }); kinda way > > So basically the App Engine examples use .run() like a formality, they > just call transaction's get methods etc. afterwards - but the direct docs > suggest everything to be inside .run() > > *Question:* I'm guessing .run() is like a formality that starts a > transaction, the transaction.get()'s etc. lock entities, and if they are > modified outside, transaction fails? - so basically, instead of a formality > .run() - the other transaction commands could've internally done this too > > And I also guess retries aren't a thing any more, so using .run() like a > formality goes - however, if the default approach was to put everything > inside the run()'s callback function, couldn't there be a retry parameter > too? > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/751431e0-f3be-4f6e-8350-3afe8a0ca438n%40googlegroups.com.
