|
|
|
|
|
by calambrac
6098 days ago
|
|
You're missing the point. Here's the basic transaction paradigm for remote resources: try:
remote_resource.start_transaction()
#dostuff
remote_resource.commit()
except e:
remote_resource.rollback()
How do you do the same thing when modifying a local variable? You might try making a copy, modifying that, and then assigning back, but that's boilerplate, and it's easy to get wrong. Worlds are a more primitive mechanism that would be baked into a language, such that building a generic transaction api for local actions on top of worlds would be trivial. The fact that it could look exactly like the transaction api that you currently know and love for remote resources is a feature. |
|
What I normally do is: operate on temporaries (or copied parameters), change remote resource (it's safe to just rollback resource changes and exit here in case of problems), then change "the state" when operations cannot fail any more. Is there any real-live problem that needs local variables rollback? (that is shorter / nicer than returning the result from temporary locals) I'd really like to see it.