Vladimir Shabanov wrote:
2010/8/24 Adam Chlipala<[email protected]>:
Vladimir Shabanov wrote:
And there is another way to check DML errors -- another function dml'
can be adder which returns option string instead of error page, e.g.
result<- dml' (...);
case result of
None => return "ok"
Some e => return strcat("dberror: ", e)
I like this suggestion. The key issue is deciding which database errors
should be returned in this way. An error like "lost connection to server"
should still abort execution, IMO, since it's outside of the abstraction
that Ur/Web is meant to present to the programmer. A corollary issue is
which methods should be used with each database system's C library to filter
out the appropriate errors.
I think that constraint violations should be returned (ideally with
name of constraint), other errors (except errors that Ur's runtime
can't handle -- like connection issues) can be just returned as string
so they still can be handled even without native Ur support.
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. :)
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
