On 11 Jan 2011, at 08:20, Max Vlasov wrote: > On Tue, Jan 11, 2011 at 3:54 AM, Richard Hipp <d...@sqlite.org> wrote: > >> >> This is, technically, a compatibility break. On the other hand, there >> appear to be vast numbers of smartphone applications that currently depend >> on undefined behavior and will suddenly stop working if we don't make this >> change. >> >> So the question to you, gentle reader, is should we make this change, and >> break backwards compatibility, albeit in a very obscure way, or should we >> be >> hard-nosed and force hundreds or perhaps thousands of smartphone >> application >> developers fix their programs? >> >> > A thought came to me. Are we talking about recompiling thousands of > application or just about applications that use sqlite with some other way > (dynamic linking or managed layer) ? If the latter (and this is possible the > case for example for managed-coded platforms such as Android), isn't it > better to introduce a define for the new functionality that doesn't exists > in the source, but the developers of the platform should add it to makefile > in order to this new feature to take effect at once for all these thousand > applications? I don't think the change itself is bad, the problem is that > "minor change syndrome" will never die and life teaches me this again and > again :)
I assume we are talking about dynamic linking: otherwise thousands of programmers have got a new amalgamation, rebuilt their apps and shipped them untested. It's not just Android: Apple ship, as part of the iPhone/iPad OS, SQLite in a dynamic library which any application can use. The problem here is twofold: 1 A variety of badly-written applications do not work with the pre-3.6.23.1 API specification when a relatively rare condition happens. 2 There is more than one possible response to this condition, and any of the available responses will be considered 'best' by someone for their application. Obviously (1) is a problem, but it isn't immediately obvious to me that it's a problem which can or should be fixed by a code change to SQLite rather than by telling the producers of badly-written applications to (a) read the docs for the APIs they use and (b) test their applications before shipping them. >From (2) it is obviously not possible to automatically handle the condition in >such a way that everyone will be happy; and any automatic handling will be an >unwelcome change in behaviour to someone. Worse, that someone may have read >the docs and written their application to the specification therein in the >first place. Incidentally the second group of apps which were broken by >3.6.23.1 may well be in this category - it is harsh to say they are >incorrectly coded, as the pre-3.6.23.1 docs and behaviour guaranteed that >SQLITE_MISUSE would eventually be returned. I think the behaviour it has now (implicit reset when that or finalize is all you can do) is a very sensible way for it to work. However, we know that breaks people who had read the pre-3.6.23.1 docs and observed that they could use SQLITE_MISUSE as a simple way to detect they were done with a statement. The proposed reset-on-error-only feels the wrong way round to me (reset-on-success-only would make more sense), and it will almost certainly still break some people. The problem I see with Max's suggested route is that you potentially end up with different semantics from SQLite on all the platforms which provide it as part of the OS, which in the long run makes it much harder for application developers. If this were a democracy I'd vote for the pre-3.6.23.1 semantics, as that's the documented API for sqlite 3. If the weight of history wasn't there, I'd probably vote for the 3.6.23.1 semantics. Orthogonally: providing some help with application testing would be useful if it's possible - for instance a #define or pragma to make all these rare conditions more likely so that they can be tested with less effort. I don't know how feasible this is. 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
