On 11 Jan 2011, at 13:36, Andy Gibbs wrote: > On Tuesday, January 11, 2011 1:35 PM, Jean-Denis Muys wrote: > >> Don't encumber SQLite with workarounds and special cases >> to cater to bugs in client software. > > Isn't an accurate synopsis of the problem this: that Sqlite has *already* > implemented a workaround in 3.7.0, and that this workaround has actually > caused a bigger problem, albeit only for "incorrectly" written code.
It has (also) caused problems for code which was correct (if not pretty) given the API as documented in the last release before 3.6.23.1. > Therefore, shouldn't this original workaround be fixed, in the way > prescribed (since for all intents and purposes the new fix is better than > the old fix)? Arguable - either 'fix' is undesirable if you have pre-3.6.23.1 code which is expecting to see SQLITE_MISUSE when it used to see it. It also makes a certain class of bugs more likely - if you get SQLITE_BUSY within an explicit transaction you should roll-back that transaction and begin it again; IMO you are more likely to notice and obey that requirement if you cannot just immediately call sqlite3_step again. That said, I like the current behaviour best of the three options, as it's less code to write in applications and it's consistent with itself. The <3.6.23.1 behaviour is also consistent, and there is a case for going back to that if the current behaviour is (with hindsight) a more-incompatible change than should have been introduced mid-release. I like the proposed new fix least, as it still requires sqlite3_reset on the normal path and creates an inconsistency between that and the abnormal path. > The issue of whether or not sqlite should provide workarounds (in future) to > cater for bugs in client software is another question, isn't it? Yes; I would expect future workaround-requesters to appeal to the precedent set this time. The precedent that SQLite can be improved at any time, and that's what happened in 3.6.23.1 so it won't be reverted is one option. This is probably what developers expect in the open-source world. The precedent that flow-affecting changes will not be put in mid-release and this 3.6.23.1 change was therefore an error that will be reverted is another. This is probably what developers expect in the commercial world. The third is the precedent that developers don't need to worry about reading the documentation and handling errors correctly as SQLite will usually be changed in a future release to make their code work. And if this change breaks someone else then SQLite will be changed again. Best Regards, Phil Willoughby -- Managing Director, StrawberryCat Limited StrawberryCat Limited is registered in England and Wales with Company No. 7234809. The registered office address of StrawberryCat Limited is: 107 Morgan Le Fay Drive Eastleigh SO53 4JH _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
