Re: [sqlite] Propose minor incompatible API change

On Tuesday, January 11, 2011 1:54 AM, Richard Hipp wrote: > 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

Re: [sqlite] Propose minor incompatible API change

On 12 Jan 2011, at 12:49, Andy Gibbs wrote: > On Wednesday, January 12, 2011 10:08 AM, Philip Graham Willoughby wrote: > >> unfortunately 3.7.2 shipped in Ubuntu Maverick and >> 3.6.23.1 shipped in a maintenance update for Fedora >> Core 14. So lots of people already have both behaviours >> in

Re: [sqlite] Propose minor incompatible API change

On Wednesday, January 12, 2011 10:08 AM, Philip Graham Willoughby wrote: > unfortunately 3.7.2 shipped in Ubuntu Maverick and > 3.6.23.1 shipped in a maintenance update for Fedora > Core 14. So lots of people already have both behaviours > in the wild. Actually, the first alteration happened

Re: [sqlite] Propose minor incompatible API change

Please don't top-post and include everything that went before. On 11 Jan 2011, at 17:10, Scott A Mintz wrote: > There's the issue of "this is what I meant" vs. "this is what I did." When > you have a couple hundred customer's, changing the code is painful but > doable. When you have a couple

Re: [sqlite] Propose minor incompatible API change

There's the issue of "this is what I meant" vs. "this is what I did." When you have a couple hundred customer's, changing the code is painful but doable. When you have a couple million customer's, then what is "out there" is the "true" API and must be kept around. Microsoft has bent over

Re: [sqlite] Propose minor incompatible API change

>An end user (think: your mom) wants to upgrade her smartphone to the >latest >OS release. That new OS release includes the latest shared library for >SQLite. But in so doing, some percentage of the apps she has downloaded >cease to work. Sure, the problem really is that the apps were

Re: [sqlite] Propose minor incompatible API change

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

Re: [sqlite] Propose minor incompatible API change

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* >

Re: [sqlite] Propose minor incompatible API change

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

Re: [sqlite] Propose minor incompatible API change

On 11 Jan 2011, at 12:15, Richard Hipp wrote: > That new OS release includes the latest shared library for > SQLite. You didn't put it there, and the consequences of putting it there are not your responsibility. Nor are the consequences of someone else's app breaking because they didn't read

Re: [sqlite] Propose minor incompatible API change

s From: sqlite-users-boun...@sqlite.org on behalf of Richard Hipp Sent: Tue 1/11/2011 6:15 AM To: General Discussion of SQLite Database Subject: EXTERNAL:Re: [sqlite] Propose minor incompatible API change I don't think I explained the problem clearly. The pr

Re: [sqlite] Propose minor incompatible API change

On 11 janv. 2011, at 13:15, Richard Hipp wrote: > On Tue, Jan 11, 2011 at 6:59 AM, Jean-Christophe Deschamps > wrote: > >> >> My rationale is that either it's technically or economically feasible >> for the offending applications' developpers to change their code to use >> the

Re: [sqlite] Propose minor incompatible API change

On Tue, Jan 11, 2011 at 6:59 AM, Jean-Christophe Deschamps wrote: > > My rationale is that either it's technically or economically feasible > for the offending applications' developpers to change their code to use > the library correctly (and that doesn't seem to be the case), OR

Re: [sqlite] Propose minor incompatible API change

>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. I understand the proposed change will have no incidence for

Re: [sqlite] Propose minor incompatible API change

I agree with this change because it doesn't change all well written programs. It just tries to correct all incorrectly written ones, which is a good thing for the end-users. ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] Propose minor incompatible API change

On Tuesday, January 11, 2011 1:54 AM, Richard Hipp wrote: > This is, technically, a compatibility break. But wasn't the original change also a compatibility break? But this time it may make it into the short-form software history at http://www.sqlite.org/changes.html? Having studied the

Re: [sqlite] Propose minor incompatible API change

On 11 janv. 2011, at 01:54, Richard Hipp wrote: > > 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 >

Re: [sqlite] Propose minor incompatible API change

On 11 Jan 2011, at 08:20, Max Vlasov wrote: > On Tue, Jan 11, 2011 at 3:54 AM, Richard Hipp 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

Re: [sqlite] Propose minor incompatible API change

On Tue, Jan 11, 2011 at 3:54 AM, Richard Hipp 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

Re: [sqlite] Propose minor incompatible API change

On Mon, Jan 10, 2011 at 9:00 PM, Igor Tandetnik wrote: ... They are stuck calling sqlite3_step - incorrectly - so the only remaining move is to modify the behavior of sqlite3_step itself, to allow them to muddle through. ... Understood and concurred. It makes sense to

Re: [sqlite] Propose minor incompatible API change

On 1/10/2011 8:52 PM, Chris Peachment wrote: > On Mon, 2011-01-10 at 19:54 -0500, Richard Hipp 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

Re: [sqlite] Propose minor incompatible API change

On Mon, Jan 10, 2011 at 8:52 PM, Chris Peachment wrote: > On Mon, 2011-01-10 at 19:54 -0500, Richard Hipp wrote: > > > > > This is, technically, a compatibility break. On the other hand, there > > appear to be vast numbers of smartphone applications that currently > depend >

Re: [sqlite] Propose minor incompatible API change

On Mon, 2011-01-10 at 19:54 -0500, Richard Hipp 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. >

[sqlite] Propose minor incompatible API change

As you probably know, the sqlite3_step() interface is used to step through the results of an SQLite query. The sqlite3_step() function returns SQLITE_ROW for every row that is returned, then SQLITE_DONE when there are no more result rows. After SQLITE_DONE (or an error) is returned, one can use