Darren Duncan wrote:
Generally, if you want your changes to be commited or rolled back when you disconnect, then you should explicitly call "commit" or "rollback" before disconnecting.
</lurk> Generally - exceptions being caused by implicit commit?
I suggest that the disconnect() function follow the same behaviour as DESTROY for how transactions are dealt with. Or in other words, any current transaction should *always* be rolled back when a database connection is closed, regardless of how it is closed. The DBD modules should do this by themselves, and hence the users of DBI can count on the "shortest/simplest path" (no explicit c/r pre disc) always being consistent. They know that they must always explicitly commit() transactions (or use auto-commit), or changes won't be saved, period.
...I will also note that this change should not break any user applications if they were doing the "right thing" to begin with, which is "be explicit", as the documentation says. Only applications that counted on undefined default behaviour to be a certain way, which is "commit", and used a database that did just that, might break.
How is that undefined? An application using a certain database, counting on the behaviour it ususally has. It seems to me
big warning signs are needed. Otoh, it does use DBI, so it should know to expect DBI behaviour. Commoditizing as you are suggesting
does leverage the power of that expectation.
