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
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 million
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 *after*
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 the wild.
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
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
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
developers fix
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
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
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
On Tue, Jan 11, 2011 at 6:59 AM, Jean-Christophe Deschamps
j...@q-e-d.orgwrote:
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 very
On 11 janv. 2011, at 13:15, Richard Hipp wrote:
On Tue, Jan 11, 2011 at 6:59 AM, Jean-Christophe Deschamps
j...@q-e-d.orgwrote:
My rationale is that either it's technically or economically feasible
for the offending applications' developpers to change their code to use
the library
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 proposed change is for the benefit of the applications customers, not
the application
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
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
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
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
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 incorrectly
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
backwards
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
On Mon, 2011-01-10 at 19:54 -0500, Richard Hipp wrote:
snip
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.
On Mon, Jan 10, 2011 at 8:52 PM, Chris Peachment ch...@ononbb.com wrote:
On Mon, 2011-01-10 at 19:54 -0500, Richard Hipp wrote:
snip
This is, technically, a compatibility break. On the other hand, there
appear to be vast numbers of smartphone applications that currently
depend
on
On 1/10/2011 8:52 PM, Chris Peachment wrote:
On Mon, 2011-01-10 at 19:54 -0500, Richard Hipp wrote:
snip
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
On Mon, Jan 10, 2011 at 9:00 PM, Igor Tandetnik itandet...@mvps.org 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
24 matches
Mail list logo
