I think that a bunch of good points have been made, especially as to why you should hold your ground.
(I don't have sympathy for poor code that doesn't follow the documentation, especially when there is a large, competent, and helpful community group that usually comes to people's aid in less than 1 day. Since when is my app's bug your core problem?) If the smartphone providers are willing to pay "enough" to fund this project to ensure it keeps going, then I guess the idea of "He who pays the piper calls the tune." applies. Having lots of apps that work well are a way these companies compete with each other. I don't like the idea of a technical decision being determined in the spirit of a bribe, but this doesn't affect well written code..... so I don't much care which side this falls on. The idea of a examples library for the docs is good, probably should have its own thread to discuss how to implement. best wishes, Adam On Tue, Jan 11, 2011 at 9:09 AM, Philip Graham Willoughby < phil.willoug...@strawberrycat.com> wrote: > 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 > -- VerifEye Technologies Inc. 905-948-0015x245 151 Whitehall Dr, Unit 2 Markham ON, L3R 9T1 Canada _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users