Re: [sqlite] SQLite version 3.6.10 - Warning

[Nicolas Williams]

On Fri, Jan 16, 2009 at 09:43:36AM +0100, Christophe Leske wrote:
> sqlite> .o cl1.sql
  ^^

This says: send output of queries to a file called "cl1.sql".

> sqlite> .dump cl1%

And this says: dump the named table.

> sqlite> select * from cl1;

And the output of this will still go to a file called "cl1.sql".

> sqlite>
> 
> Also, a .show statement returns nothing either. It seems as if the 
> database does simply not exist anymore.

Look:

% sqlite3 /tmp/xdb
SQLite version 3.6.9
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table t(a);
sqlite> insert into t values (1);
sqlite> .o /tmp/xyz
sqlite> .dump t
sqlite> select * from t;
sqlite> .show
sqlite> .o stdout
sqlite> select * from t;
1
sqlite> .dump t
BEGIN TRANSACTION;
CREATE TABLE t(a);
INSERT INTO "t" VALUES(1);
COMMIT;
sqlite> .show
 echo: off
  explain: off
  headers: off
 mode: list
nullvalue: ""
   output: stdout
separator: "|"
width: 
sqlite> ^D
% sqlite3 /tmp/xdb
SQLite version 3.6.9
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .dump t
BEGIN TRANSACTION;
CREATE TABLE t(a);
INSERT INTO "t" VALUES(1);
COMMIT;
sqlite> ^D
% 

Nico
-- 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10 - Warning

[Christophe Leske]

> After you complete your ".dump" do:
>
> .output stdout
>   
Ok, that was stupid, my apologies.

Yet somehow this used to work i think...

Still, when rereading the dumped table, it does not reread the values 
correctly for the rtree table.

I am sorry, I must go now, I can provide further information on the 25th.

Thank you for your patience,

-- 
Christophe Leske

www.multimedial.de - i...@multimedial.de
http://www.linkedin.com/in/multimedial
Lessingstr. 5 - 40227 Duesseldorf - Germany
0211 261 32 12 - 0177 249 70 31


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10 - Warning

[D. Richard Hipp]

On Jan 16, 2009, at 3:42 AM, Christophe Leske wrote:

>
>> Try instead:
>>
>>.dump cl1%
> Apparently, this doesn´t help either. Once I tried to export the  
> table, the application refuses to show the entries in the table.
>
> The database i am opening here is correct, it holds data in cl1  
> prior to opening it for this step here:
>
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> C:\Arbeit\Arbeit\__Projekte\2007\MMCD\SRC\globe\DB>sqlite3  
> countries2.db
> SQLite version 3.6.10
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> .o cl1.sql
> sqlite> .dump cl1%
> sqlite> select * from cl1;
> sqlite>
>
> Also, a .show statement returns nothing either. It seems as if the  
> database does simply not exist anymore.
>

Everything is still working normally.  But the output is all going  
into the file named "cl1.sql", as you requested on the first line.  
After you complete your ".dump" do:

.output stdout

To cause output to go to the screen again.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10 - Warning

[D. Richard Hipp]

On Jan 16, 2009, at 3:43 AM, Christophe Leske wrote:
>
> Do you want me to mail you the corrupted database for further
> inspection? I also understand that this is not the right place for
> bugreports eventually.


No.  Email me the original, uncorrupted database and instructions for  
how to make the corruption occur.


D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10 - Warning

[Christophe Leske]

> Try instead:
>
> .dump cl1%
Apparently, this doesn´t help either. Once I tried to export the table, the 
application refuses to show the entries in the table. 

The database i am opening here is correct, it holds data in cl1 prior to 
opening it for this step here:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Arbeit\Arbeit\__Projekte\2007\MMCD\SRC\globe\DB>sqlite3 countries2.db
SQLite version 3.6.10
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .o cl1.sql
sqlite> .dump cl1%
sqlite> select * from cl1;
sqlite>

Also, a .show statement returns nothing either. It seems as if the database 
does simply not exist anymore. 

Furthermore, i got a corrupted version of the database here as the result of my 
operations as well - this used to be the same database than the one above, yet 
after exporting and reimporting the data for the cl1 table, it is now 
corrupted. 

C:\Arbeit\Arbeit\__Projekte\2007\MMCD\SRC\globe\DB>sqlite3 countries-corrupted.d
b
SQLite version 3.6.10
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .s
sqlite> .s cl1;
sqlite>

We also experience crashes with the new version, but this may be due to the 
component we are using (i am not sure it is supporting the new version of 
sqlite.dll)


Do you want me to mail you the corrupted database for further inspection? I 
also understand that this is not the right place for bugreports eventually.

Christophe Leske

www.multimedial.de - i...@multimedial.de
http://www.linkedin.com/in/multimedial
Lessingstr. 5 - 40227 Duesseldorf - Germany
0211 261 32 12 - 0177 249 70 31


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Christophe Leske]

Jim Dodgen schrieb:
> I'm a strong believer in the "continuous  improvement" philosophy. Keep up
> the good work.
>   
Same here. Better fix stuff as you know of it.

Please keep up the great work with SQlite, i never used such a good and 
sturdy tool that just did what it was supposed to do.

I think this is what I like best about it:
it does the stuff it is supposed to do, no more, but also not less.

-- 
Christophe Leske

www.multimedial.de - i...@multimedial.de
http://www.linkedin.com/in/multimedial
Lessingstr. 5 - 40227 Duesseldorf - Germany
0211 261 32 12 - 0177 249 70 31


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Alexey Pechnikov]

Hello!

В сообщении от Thursday 15 January 2009 20:07:49 D. Richard Hipp написал(а):
> All this is to say that we believe that SQLite version 3.6.10 is the  
> most stable, most thoroughly tested, and bug-free version of SQLite  
> that has ever existed. Please do not be freaked out by three releases  
> occurring in one week.

I'm using new releases for development and previos releases for production and 
I'm very glad to get 
new vesions quickly. Now 3.6.3 work fine for my production servers and 3.6.7 
for testing servers 
and it's easy to upgrade. If I will need in some new features then I will 
upgrade to last version 
on testing server and after some time of my application development on 
production servers. 

It's good to public releases faster and it's application development catalyst.

Best regards, Alexey.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Alexey Pechnikov]

Hello!

В сообщении от Friday 16 January 2009 00:16:43 Thomas Hertweck написал(а):
> It would not make sense to delay bug fixes, but have you ever thought
> about using a different version number scheme? In the Linux kernel
> development

Linux kernel versions compability is bad and so version number is more complex.

Best regards, Alexey.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10 - Warning

[Christophe Leske]

> Try instead:
>
> .dump cl1%
Apparently, this doesn´t help either. Once I tried to export the table, 
the application refuses to show the entries in the table.

The database i am opening here is correct, it holds data in cl1 prior to 
opening it for this step here:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Arbeit\Arbeit\__Projekte\2007\MMCD\SRC\globe\DB>sqlite3 countries2.db
SQLite version 3.6.10
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .o cl1.sql
sqlite> .dump cl1%
sqlite> select * from cl1;
sqlite>

Also, a .show statement returns nothing either. It seems as if the 
database does simply not exist anymore.

Furthermore, i got a corrupted version of the database here as the 
result of my operations as well - this used to be the same database than 
the one above, yet after exporting and reimporting the data for the cl1 
table, it is now corrupted.

C:\Arbeit\Arbeit\__Projekte\2007\MMCD\SRC\globe\DB>sqlite3 
countries-corrupted.d
b
SQLite version 3.6.10
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .s
sqlite> .s cl1;
sqlite>

We also experience crashes with the new version, but this may be due to 
the component we are using (i am not sure it is supporting the new 
version of sqlite.dll)


Do you want me to mail you the corrupted database for further 
inspection? I also understand that this is not the right place for 
bugreports eventually.

Christophe Leske

www.multimedial.de - i...@multimedial.de
http://www.linkedin.com/in/multimedial
Lessingstr. 5 - 40227 Duesseldorf - Germany
0211 261 32 12 - 0177 249 70 31



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Dan]

On Jan 16, 2009, at 4:27 AM, Nicolas Williams wrote:

> On Thu, Jan 15, 2009 at 10:07:29AM -0800, Brown, Daniel wrote:
>> The frequent releases are not a problem as far as I am concerned.   
>> I'd
>> rather have bugs fixed quickly when they are discovered, than wait
>> months for releases containing needed fixes like other libraries.  We
>> use the loose pre-generated C files (not the amalgamation) and even  
>> then
>> it only takes me about 10-20 minutes to integrate a new release and
>> about another 10-40 minutes to run it through our unit tests.
>
> I agree, but note that I run gmake fulltest.  In 3.6.9 gmake fulltest
> takes many hours (on and amd64 Solaris system it's been running since
> yesterday, and it's still not finished -- it's currently at
> savepoint4-2.11.1.7814, and making progress).
>
> Is this indicative of a performance regression in 3.6.9?  Or just a
> result of a massively increased number of tests?  3.5.4's fulltest had
> ~6 individual tests, 3.6.9's has ~38, a more than six-fold
> increment!
>
> Incidentally, on Solaris I get the following failures in 3.6.9 gmake
> fulltest:
>
> altermalloc-1.transient.40...
> Expected: [1 1]
> Got: [0 {}]
> attachmalloc-1.transient.40...
> Expected: [1 1]
> Got: [0 {}]
> malloc6-1.transient.40...
> Expected: [1 1]
> Got: [0 {}]
> mallocG-1.transient.40...
> Expected: [1 1]
> Got: [0 {}]
> savepoint3-2.transient.4819...
> Expected: [1 1]
> Got: [1 {unable to open database file}]
> savepoint6-smallcache.294.2...
> Error: no such table: t1
> savepoint6-smallcache.295.1...
> Error: no such table: t1

Do you enable FTS3? I think that may be causing the malloc errors
(which are fairly benign). The savepoint error is interesting.

Dan.


>
> ...
>
> The savepoint errors went away when I re-ran just those tests, so I
> think those were a transient issue with my test system.
>
> I can't figure out how to run just the malloc tests (putting them in  
> the
> INCLUDE list in veryquick.test doesn't do it).  Should I be concerned?
>
> I'm also seeing ticket #3205, but that's a problem with Tcl and not a
> show stopper for me.
>
> Nico
> -- 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Robert L Cochran]

Please keep up the great work. I appreciate your fixing major,
identified bugs as fast as possible.

Bob Cochran


D. Richard Hipp wrote:
> SQLite version 3.6.10 is now available on the website.  Upgrading is  
> recommended for all users.
>
> http://www.sqlite.org/
> http://www.sqlite.org/news.html
> http://www.sqlite.org/download.html
>
> SQLite version 3.6.10 fixes a cache coherency bug (Ticket #3584)  
> introduced by check-in [5864]  which was part of version 3.6.5. This  
> bug might lead to database corruption, hence we felt it was important  
> to get it out as quickly as possible, even though there had already  
> been two prior releases this week.
>
> Some concern has been expressed that we are releasing too frequently.  
> (Three releases in one week is a lot!) The concern is that this  
> creates the impression of volatility and unreliability. We have been  
> told that we should delay releases in order to create the impression  
> of stability. But the SQLite developers feel that truth is more  
> important than perception, not the other way around. We think it is  
> important to make the highest quality and most stable version of  
> SQLite available to users at all times. This week has seen two  
> important bugs being discovered shortly after a major release, and so  
> we have issued two emergency patch releases after the regularly  
> scheduled major release. This makes us look bad. This puts "egg on our  
> face." We do not like that. But, three releases also ensures that the  
> best quality SQLite code base is available available to you at all  
> times.
>
> It has been suggested that "beta" releases might find these kinds of  
> bugs prior to a major release. But our experience indicates otherwise.  
> The two issues that prompted releases 3.6.9 and 3.6.10 were both  
> discovered by internal testing and review - not by external users.  
> And, indeed, most the problems found in SQLite these days are  
> discovered by our rigorous internal testing protocol, not bug reports  
> from the field.
>
> It has also been argued that we should withhold releases "until  
> testing is finished." The falacy there is that we never finish  
> testing. We are constantly writing new test cases for SQLite and  
> thinking of new ways to stress and potentially break the code. This is  
> a continuous, never-ending, and on-going process. All existing tests  
> pass before each release. But we will always be writing new tests the  
> day after a release, regardless of how long we delay that release. And  
> sometimes those new tests will uncover new problems.
>
> All this is to say that we believe that SQLite version 3.6.10 is the  
> most stable, most thoroughly tested, and bug-free version of SQLite  
> that has ever existed. Please do not be freaked out by three releases  
> occurring in one week.
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
>   
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Nicolas Williams]

On Thu, Jan 15, 2009 at 10:07:29AM -0800, Brown, Daniel wrote:
> The frequent releases are not a problem as far as I am concerned.  I'd
> rather have bugs fixed quickly when they are discovered, than wait
> months for releases containing needed fixes like other libraries.  We
> use the loose pre-generated C files (not the amalgamation) and even then
> it only takes me about 10-20 minutes to integrate a new release and
> about another 10-40 minutes to run it through our unit tests.

I agree, but note that I run gmake fulltest.  In 3.6.9 gmake fulltest
takes many hours (on and amd64 Solaris system it's been running since
yesterday, and it's still not finished -- it's currently at
savepoint4-2.11.1.7814, and making progress).

Is this indicative of a performance regression in 3.6.9?  Or just a
result of a massively increased number of tests?  3.5.4's fulltest had
~6 individual tests, 3.6.9's has ~38, a more than six-fold
increment!

Incidentally, on Solaris I get the following failures in 3.6.9 gmake
fulltest:

altermalloc-1.transient.40...
Expected: [1 1]
 Got: [0 {}]
attachmalloc-1.transient.40...
Expected: [1 1]
 Got: [0 {}]
malloc6-1.transient.40...
Expected: [1 1]
 Got: [0 {}]
mallocG-1.transient.40...
Expected: [1 1]
 Got: [0 {}]
savepoint3-2.transient.4819...
Expected: [1 1]
 Got: [1 {unable to open database file}]
savepoint6-smallcache.294.2...
Error: no such table: t1
savepoint6-smallcache.295.1...
Error: no such table: t1
...

The savepoint errors went away when I re-ran just those tests, so I
think those were a transient issue with my test system.

I can't figure out how to run just the malloc tests (putting them in the
INCLUDE list in veryquick.test doesn't do it).  Should I be concerned?

I'm also seeing ticket #3205, but that's a problem with Tcl and not a
show stopper for me.

Nico
-- 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Thomas Hertweck]

D. Richard Hipp wrote:
> [...]
> Some concern has been expressed that we are releasing too frequently.  
> (Three releases in one week is a lot!) The concern is that this  
> creates the impression of volatility and unreliability. We have been  
> told that we should delay releases in order to create the impression  
> of stability. But the SQLite developers feel that truth is more  
> important than perception, not the other way around. We think it is  
> important to make the highest quality and most stable version of  
> SQLite available to users at all times. This week has seen two  
> important bugs being discovered shortly after a major release, and so  
> we have issued two emergency patch releases after the regularly  
> scheduled major release. This makes us look bad. This puts "egg on our  
> face." We do not like that. But, three releases also ensures that the  
> best quality SQLite code base is available available to you at all  
> times.
> [...]

It would not make sense to delay bug fixes, but have you ever thought
about using a different version number scheme? In the Linux kernel
development, a fourth digit has officially been introduced with kernel
version 2.6.11. A release with four digits resolves true and confirmed
bugs only and contains no further changes at all. This means, for
instance, if sqlite 3.6.8 is considered to be the stable release, then a
pure bug fix as described above would become release 3.6.8.1 (instead of
3.6.9) and if you had to ship yet another one, it would become 3.6.8.2
(instead of 3.6.10). The next release with more than just a pure bug fix
would then become 3.6.9 (as opposed to, say, 3.6.11 in the current version
number scheme). For an example, have a look at the directory listing of
http://www.kernel.org/pub/linux/kernel/v2.6/.

While such an approach doesn't change anything from a technical point of
view (you ship exactly the same number of releases as before), it may help
to tackle at least some of the concerns mentioned in your email and it may
allow everybody to distinguish between feature and pure bug fix releases
more easily. It certainly offers a more fine-grained control over the
version numbers.

Just an idea...
Thomas

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Richard Klein]

D. Richard Hipp wrote:
> All this is to say that we believe that SQLite version 3.6.10 is the  
> most stable, most thoroughly tested, and bug-free version of SQLite  
> that has ever existed. Please do not be freaked out by three releases  
> occurring in one week.
> 
Not freaked out at all.  Release every day if you have to.
Thanks to you and the team for such a wonderful product.

- Richard Klein

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[John Elrick]

D. Richard Hipp wrote:

SNIP
> Some concern has been expressed that we are releasing too frequently.  
> (Three releases in one week is a lot!) The concern is that this  
> creates the impression of volatility and unreliability. 

SNIP

Most software releases have a few latent bugs within them.  
Occasionally, they are serious enough to require immediate releases and 
are obscure enough they don't evidence themselves until they hit the 
field.  I tend to wait a few weeks after an SQLite release before 
looking at incorporating it "just in case".  In doing so, I follow a 
pattern I use for any software release.

SQLite has earned the reputation of being highly reliable and stable.  A 
single spat of multiple releases is a statistical blip, not a pattern.

Keep up the good work,


John Elrick
Senior IT Specialist
Fenestra Technologies
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite version 3.6.10: Memory savings with large pages

[Brown, Daniel]

Good morning list,

Has anyone else noticed significant memory savings when using larger
page sizes since upgrading to 3.6.9 or 3.6.10 (we were on 3.6.1
previously)?  We use about 7.32 MB (Peak 9.64 MB) when loading our
database into RAM using default settings and using larger page sizes
(PRAGMA page_size = 4096) used to not affect memory usage much.  Since
the upgrade we are now using only 5.65 MB (Peak 8.00 MB) loading the
same database using larger pages, very impressive!

Cheers,

Daniel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Jim Dodgen]

I'm a strong believer in the "continuous  improvement" philosophy. Keep up
the good work.



On Thu, Jan 15, 2009 at 10:07 AM, Brown, Daniel <dpbr...@ea.com> wrote:

> The frequent releases are not a problem as far as I am concerned.  I'd
> rather have bugs fixed quickly when they are discovered, than wait
> months for releases containing needed fixes like other libraries.  We
> use the loose pre-generated C files (not the amalgamation) and even then
> it only takes me about 10-20 minutes to integrate a new release and
> about another 10-40 minutes to run it through our unit tests.
>
> Daniel
>
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Mike McGonagle
> Sent: Thursday, January 15, 2009 9:57 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] SQLite version 3.6.10
>
> Thank you for these releases, I appreciate (and agree) with your
> reasons for the many releases. For me, it really is so simple that all
> I do is take the Amalgamated version and swap it out for the previous
> version. I can only think that anyone who has troubles with a swap
> like this may be doing things that are either undocumented, or are to
> get around things they want to do...
>
> just my $0.02...
>
> Thanks again.
>
> Michael McGonagle
>
> On Thu, Jan 15, 2009 at 11:07 AM, D. Richard Hipp <d...@hwaci.com> wrote:
> > SQLite version 3.6.10 is now available on the website.  Upgrading is
> > recommended for all users.
> >
> >http://www.sqlite.org/
> >http://www.sqlite.org/news.html
> >http://www.sqlite.org/download.html
> >
> > SQLite version 3.6.10 fixes a cache coherency bug (Ticket #3584)
> > introduced by check-in [5864]  which was part of version 3.6.5. This
> > bug might lead to database corruption, hence we felt it was important
> > to get it out as quickly as possible, even though there had already
> > been two prior releases this week.
> >
> > Some concern has been expressed that we are releasing too frequently.
> > (Three releases in one week is a lot!) The concern is that this
> > creates the impression of volatility and unreliability. We have been
> > told that we should delay releases in order to create the impression
> > of stability. But the SQLite developers feel that truth is more
> > important than perception, not the other way around. We think it is
> > important to make the highest quality and most stable version of
> > SQLite available to users at all times. This week has seen two
> > important bugs being discovered shortly after a major release, and so
> > we have issued two emergency patch releases after the regularly
> > scheduled major release. This makes us look bad. This puts "egg on our
> > face." We do not like that. But, three releases also ensures that the
> > best quality SQLite code base is available available to you at all
> > times.
> >
> > It has been suggested that "beta" releases might find these kinds of
> > bugs prior to a major release. But our experience indicates otherwise.
> > The two issues that prompted releases 3.6.9 and 3.6.10 were both
> > discovered by internal testing and review - not by external users.
> > And, indeed, most the problems found in SQLite these days are
> > discovered by our rigorous internal testing protocol, not bug reports
> > from the field.
> >
> > It has also been argued that we should withhold releases "until
> > testing is finished." The falacy there is that we never finish
> > testing. We are constantly writing new test cases for SQLite and
> > thinking of new ways to stress and potentially break the code. This is
> > a continuous, never-ending, and on-going process. All existing tests
> > pass before each release. But we will always be writing new tests the
> > day after a release, regardless of how long we delay that release. And
> > sometimes those new tests will uncover new problems.
> >
> > All this is to say that we believe that SQLite version 3.6.10 is the
> > most stable, most thoroughly tested, and bug-free version of SQLite
> > that has ever existed. Please do not be freaked out by three releases
> > occurring in one week.
> >
> > D. Richard Hipp
> > d...@hwaci.com
> >
> >
> >
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
>
>
>
> --
> Peace may sound simple-one beautif

Re: [sqlite] SQLite version 3.6.10

[Brown, Daniel]

The frequent releases are not a problem as far as I am concerned.  I'd
rather have bugs fixed quickly when they are discovered, than wait
months for releases containing needed fixes like other libraries.  We
use the loose pre-generated C files (not the amalgamation) and even then
it only takes me about 10-20 minutes to integrate a new release and
about another 10-40 minutes to run it through our unit tests.

Daniel

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Mike McGonagle
Sent: Thursday, January 15, 2009 9:57 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLite version 3.6.10

Thank you for these releases, I appreciate (and agree) with your
reasons for the many releases. For me, it really is so simple that all
I do is take the Amalgamated version and swap it out for the previous
version. I can only think that anyone who has troubles with a swap
like this may be doing things that are either undocumented, or are to
get around things they want to do...

just my $0.02...

Thanks again.

Michael McGonagle

On Thu, Jan 15, 2009 at 11:07 AM, D. Richard Hipp <d...@hwaci.com> wrote:
> SQLite version 3.6.10 is now available on the website.  Upgrading is
> recommended for all users.
>
>http://www.sqlite.org/
>http://www.sqlite.org/news.html
>http://www.sqlite.org/download.html
>
> SQLite version 3.6.10 fixes a cache coherency bug (Ticket #3584)
> introduced by check-in [5864]  which was part of version 3.6.5. This
> bug might lead to database corruption, hence we felt it was important
> to get it out as quickly as possible, even though there had already
> been two prior releases this week.
>
> Some concern has been expressed that we are releasing too frequently.
> (Three releases in one week is a lot!) The concern is that this
> creates the impression of volatility and unreliability. We have been
> told that we should delay releases in order to create the impression
> of stability. But the SQLite developers feel that truth is more
> important than perception, not the other way around. We think it is
> important to make the highest quality and most stable version of
> SQLite available to users at all times. This week has seen two
> important bugs being discovered shortly after a major release, and so
> we have issued two emergency patch releases after the regularly
> scheduled major release. This makes us look bad. This puts "egg on our
> face." We do not like that. But, three releases also ensures that the
> best quality SQLite code base is available available to you at all
> times.
>
> It has been suggested that "beta" releases might find these kinds of
> bugs prior to a major release. But our experience indicates otherwise.
> The two issues that prompted releases 3.6.9 and 3.6.10 were both
> discovered by internal testing and review - not by external users.
> And, indeed, most the problems found in SQLite these days are
> discovered by our rigorous internal testing protocol, not bug reports
> from the field.
>
> It has also been argued that we should withhold releases "until
> testing is finished." The falacy there is that we never finish
> testing. We are constantly writing new test cases for SQLite and
> thinking of new ways to stress and potentially break the code. This is
> a continuous, never-ending, and on-going process. All existing tests
> pass before each release. But we will always be writing new tests the
> day after a release, regardless of how long we delay that release. And
> sometimes those new tests will uncover new problems.
>
> All this is to say that we believe that SQLite version 3.6.10 is the
> most stable, most thoroughly tested, and bug-free version of SQLite
> that has ever existed. Please do not be freaked out by three releases
> occurring in one week.
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Peace may sound simple-one beautiful word- but it requires everything
we have, every quality, every strength, every dream, every high ideal.
-Yehudi Menuhin (1916-1999), musician
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10 - Warning

[D. Richard Hipp]

On Jan 15, 2009, at 12:43 PM, Christophe Leske wrote:

> Hi,
>
> if my findings are not mistaken, then the commandline executable of  
> the
> new version has some serious problems:
>
> I have a database (which seems correct so far) from which I would like
> to dump a table called "cl1" which is a virtual table using an rtree:
>
> sqlite> .o cl1.sql
> sqlite> .d cl1

Try instead:

 .dump cl1%

>
> sqlite> drop table cl1;
> SQL error: no such table: main.cl1_node
>
> After exporting the table, it seems that there is some corruption  
> going on?
>
> Also, when trying to import the data, the data is not read back
> correctly (the number ordering gets out of whack).
>
> I am in the midst of signing off my project, but how can I  
> contribute ?
>
> -- 
> Christophe Leske
>
> www.multimedial.de - i...@multimedial.de
> http://www.linkedin.com/in/multimedial
> Lessingstr. 5 - 40227 Duesseldorf - Germany
> 0211 261 32 12 - 0177 249 70 31
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Mike McGonagle]

Thank you for these releases, I appreciate (and agree) with your
reasons for the many releases. For me, it really is so simple that all
I do is take the Amalgamated version and swap it out for the previous
version. I can only think that anyone who has troubles with a swap
like this may be doing things that are either undocumented, or are to
get around things they want to do...

just my $0.02...

Thanks again.

Michael McGonagle

On Thu, Jan 15, 2009 at 11:07 AM, D. Richard Hipp  wrote:
> SQLite version 3.6.10 is now available on the website.  Upgrading is
> recommended for all users.
>
>http://www.sqlite.org/
>http://www.sqlite.org/news.html
>http://www.sqlite.org/download.html
>
> SQLite version 3.6.10 fixes a cache coherency bug (Ticket #3584)
> introduced by check-in [5864]  which was part of version 3.6.5. This
> bug might lead to database corruption, hence we felt it was important
> to get it out as quickly as possible, even though there had already
> been two prior releases this week.
>
> Some concern has been expressed that we are releasing too frequently.
> (Three releases in one week is a lot!) The concern is that this
> creates the impression of volatility and unreliability. We have been
> told that we should delay releases in order to create the impression
> of stability. But the SQLite developers feel that truth is more
> important than perception, not the other way around. We think it is
> important to make the highest quality and most stable version of
> SQLite available to users at all times. This week has seen two
> important bugs being discovered shortly after a major release, and so
> we have issued two emergency patch releases after the regularly
> scheduled major release. This makes us look bad. This puts "egg on our
> face." We do not like that. But, three releases also ensures that the
> best quality SQLite code base is available available to you at all
> times.
>
> It has been suggested that "beta" releases might find these kinds of
> bugs prior to a major release. But our experience indicates otherwise.
> The two issues that prompted releases 3.6.9 and 3.6.10 were both
> discovered by internal testing and review - not by external users.
> And, indeed, most the problems found in SQLite these days are
> discovered by our rigorous internal testing protocol, not bug reports
> from the field.
>
> It has also been argued that we should withhold releases "until
> testing is finished." The falacy there is that we never finish
> testing. We are constantly writing new test cases for SQLite and
> thinking of new ways to stress and potentially break the code. This is
> a continuous, never-ending, and on-going process. All existing tests
> pass before each release. But we will always be writing new tests the
> day after a release, regardless of how long we delay that release. And
> sometimes those new tests will uncover new problems.
>
> All this is to say that we believe that SQLite version 3.6.10 is the
> most stable, most thoroughly tested, and bug-free version of SQLite
> that has ever existed. Please do not be freaked out by three releases
> occurring in one week.
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Peace may sound simple—one beautiful word— but it requires everything
we have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10 - Warning

[Christophe Leske]

Hi,

if my findings are not mistaken, then the commandline executable of the 
new version has some serious problems:

I have a database (which seems correct so far) from which I would like 
to dump a table called "cl1" which is a virtual table using an rtree:

sqlite> .o cl1.sql
sqlite> .d cl1
sqlite> drop table cl1;
SQL error: no such table: main.cl1_node

After exporting the table, it seems that there is some corruption going on?

Also, when trying to import the data, the data is not read back 
correctly (the number ordering gets out of whack).

I am in the midst of signing off my project, but how can I contribute ?

-- 
Christophe Leske

www.multimedial.de - i...@multimedial.de
http://www.linkedin.com/in/multimedial
Lessingstr. 5 - 40227 Duesseldorf - Germany
0211 261 32 12 - 0177 249 70 31


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.6.10

[Nicolas Williams]

I wholly agree that release frequency should mirror the frequency of
serious bugs and their fixes.  SQLite3 rarely has serious bugs.  Two in
one week (one dating to a much earlier version) is out of the ordinary
for SQLite3, but not particularly worrisome.

And agree with your comments about testing.

Nico
-- 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite version 3.6.10

[D. Richard Hipp]

SQLite version 3.6.10 is now available on the website.  Upgrading is  
recommended for all users.

http://www.sqlite.org/
http://www.sqlite.org/news.html
http://www.sqlite.org/download.html

SQLite version 3.6.10 fixes a cache coherency bug (Ticket #3584)  
introduced by check-in [5864]  which was part of version 3.6.5. This  
bug might lead to database corruption, hence we felt it was important  
to get it out as quickly as possible, even though there had already  
been two prior releases this week.

Some concern has been expressed that we are releasing too frequently.  
(Three releases in one week is a lot!) The concern is that this  
creates the impression of volatility and unreliability. We have been  
told that we should delay releases in order to create the impression  
of stability. But the SQLite developers feel that truth is more  
important than perception, not the other way around. We think it is  
important to make the highest quality and most stable version of  
SQLite available to users at all times. This week has seen two  
important bugs being discovered shortly after a major release, and so  
we have issued two emergency patch releases after the regularly  
scheduled major release. This makes us look bad. This puts "egg on our  
face." We do not like that. But, three releases also ensures that the  
best quality SQLite code base is available available to you at all  
times.

It has been suggested that "beta" releases might find these kinds of  
bugs prior to a major release. But our experience indicates otherwise.  
The two issues that prompted releases 3.6.9 and 3.6.10 were both  
discovered by internal testing and review - not by external users.  
And, indeed, most the problems found in SQLite these days are  
discovered by our rigorous internal testing protocol, not bug reports  
from the field.

It has also been argued that we should withhold releases "until  
testing is finished." The falacy there is that we never finish  
testing. We are constantly writing new test cases for SQLite and  
thinking of new ways to stress and potentially break the code. This is  
a continuous, never-ending, and on-going process. All existing tests  
pass before each release. But we will always be writing new tests the  
day after a release, regardless of how long we delay that release. And  
sometimes those new tests will uncover new problems.

All this is to say that we believe that SQLite version 3.6.10 is the  
most stable, most thoroughly tested, and bug-free version of SQLite  
that has ever existed. Please do not be freaked out by three releases  
occurring in one week.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users