Vladimir Shabanov wrote:
2010/9/5 Adam Chlipala<[email protected]>:
I've started implementing this. Everything works, save that the semantics
differs between Postgres and MySQL/SQLite. Postgres won't let you continue
using a transaction after one command has failed, whereas MySQL and SQLite
allow many errors within one transaction. (Remember that every Ur/Web page
execution is implicitly inside a single transaction.) What does everyone
think about whether that semantics is acceptable for Ur/Web? The more
liberal semantics can be implemented for Postgres using savepoints, but it
would decrease performance. If no one would want to keep running SQL after
an error, then there doesn't seem to be a reason to do more work.
Personally, I'm in favor of never using this new feature, anyway, but I'm
interested in what y'all who argued for it think. :)
I think it would be nice to have possibility to manually restart
transaction so DB still can be accessed after error.
After I sent the above message, I realized that some kind of
compensating action was necessary to make this feature at all useful for
Postgres. Otherwise, a transaction wouldn't be able to commit after an
error, so any actions an application had taken in response to the error
would be rolled back. Because of this, I'm planning to add a savepoint
before every piece of DML executed by the new function.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
