519270 - Upgrade to SQLite 3.6.18

Status: RESOLVED WONTFIX

(Toolkit :: Storage, defect, P2)

Description

[Shawn Wilsher :sdwilsh]

We are now two revisions of SQLite behind on mozilla-central.  We should fix this.

Comment 1

[Shawn Wilsher :sdwilsh]

Attachment: v1.0

Mozilla needed changes.

I'm not going to request review on these changes anymore since it doesn't add any value to the process.  The upgrade process has been the same for over a year now and it's trivial to do.

Pushed this to the try server, and I'll push it to mozilla-central if everything goes over well.

Comment 2

[Peter Weilbacher]

While I agree that you do not need r+ on such a trivial Mozilla patch, I disagree that you check stuff in without getting r+ at all. Every library update of external code in the Mozilla tree needs and gets reviewed (e.g. libpng and cairo), I don't see why SQLite should make an exception. It is neither NPOTB nor test code which are both exempt from reviews.

The reviewer should at least check that updating makes sense, and that the new SQLite version has features or fixes that are needed. (It would also be nice, if you would spell out the reasons in your bug comment. At least here we have dependent bugs that tell part of the story.)

Comment 3

[Shawn Wilsher :sdwilsh]

What I didn't include in this bug is the long conversation that happened in IRC about this.  It turns out we don't do reviews for other library drops either (video stuff and cairo were both discussed).

Generally, I like to keep mozilla-central in line with the latest SQLite, but I've been busy with other stuff and haven't been able to.  While I could give a long drawn out reason why we should upgrade each time, nobody really seems to care why or when I upgrade SQLite except for me (because I get roped in on any bug involving SQLite or storage).  I'm happy to answer questions when people need them, but in the common case it seems like a waste of time.

Comment 4

[Peter Weilbacher]

By that reasoning you could also stop filing bugs about it and just do it. There are many things in the Mozilla process that waste time but we still them because it helps openness.

But I know that I care, every time (and with many of the libraries in the tree). Because I support Mozilla stuff on a platform that try server tests don't cover, so every update causes me additional work, too. And if there is a strong reason for upgrading (like a crash fix), then I should in principle try to test the fix on my platform (just that I rarely have time to do that).

Btw, people on IRC were wrong, at least about cairo (see bug 498428) which did land with reviews.

All that said, if I'm really the only one who cares, and the Mozilla project decides (or has decided?) that we can update external libraries without reviews, then I won't stand in the way of simplifying the process.

Comment 5

[Shawn Wilsher :sdwilsh]

That's interesting since I was talking to Jeff on irc specifically.  Regardless, mconnor gave me blanket rs for SQLite upgrades as long as the only thing I'm changing is the configure.in and README.MOZILLA file + the SQLite files.  I'll continue to file bugs just so people who watch this component (like yourself) will know when we plan on upgrading because it's useful to establish bug dependencies.  I'll be doing more and more storage work in the coming months, and that may require upgrading SQLite to get new APIs.

Comment 6

[Mike Connor [:mconnor]]

rs=me on all sqlite upgrades that are drop-in replacments.  We have sufficient unit test coverage in place to ensure quality doesn't suffer, and we trust upstream in this case.

(If we break compatibility or wrappers in any way at all, this blanket statement does not apply.)

Comment 7

[Peter Weilbacher]

OK, great, thanks guys. :-)

Comment 8

[Shawn Wilsher :sdwilsh]

http://hg.mozilla.org/mozilla-central/rev/e0e16a509fb6
http://hg.mozilla.org/mozilla-central/rev/9efec43b4e41

Comment 9

[Shawn Wilsher :sdwilsh]

Comment on attachment 403825 [details] [diff] [review]
v1.0

I'd like to get this on 1.9.2 before the beta.

Comment 10

[Daniel C]

I'd just like to say in response to comment 3 ("nobody really seems to
care why or when I upgrade SQLite except for me") that this isn't true and that there are probably a lot of people who are interested but keep quiet.

For anyone looking for the changes, they are at: http://sqlite.org/changes.html

I don't think it takes too much to copy the few lines of changes each time an upgrade bug is filed.

2009 Sep 11 (3.6.18)

    * Versioning of the SQLite source code has transitioned from CVS to Fossil.
    * Query planner enhancements.
    * The SQLITE_ENABLE_STAT2 compile-time option causes the ANALYZE command to collect a small histogram of each index, to help SQLite better select among competing range query indices.
    * Recursive triggers can be enabled using the PRAGMA recursive_triggers statement.
    * Delete triggers fire when rows are removed due to a REPLACE conflict resolution. This feature is only enabled when recursive triggers are enabled.
    * Added the SQLITE_OPEN_SHAREDCACHE and SQLITE_OPEN_PRIVATECACHE flags for sqlite3_open_v2() used to override the global shared cache mode settings for individual database connections.
    * Added improved version identification features: C-Preprocessor macro SQLITE_SOURCE_ID, C/C++ interface sqlite3_sourceid(), and SQL function sqlite_source_id().
    * Obscure bug fix on triggers ([efc02f9779]). 

2009 Aug 10 (3.6.17)

    * Expose the sqlite3_strnicmp() interface for use by extensions and applications.
    * Remove the restriction on virtual tables and shared cache mode. Virtual tables and shared cache can now be used at the same time.
    * Many code simplifications and obscure bug fixes in support of providing 100% branch test coverage.

Comment 11

[Shawn Wilsher :sdwilsh]

(In reply to comment #10)
> I don't think it takes too much to copy the few lines of changes each time an
> upgrade bug is filed.
That's assuming that the reason I'm taking an upgrade is listed there.  More often than not I'm upgrading it because we want to stay current.

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Shawn, can you tell if bug 520541 is somehow related to the upgrade?

Comment 13

[Shawn Wilsher :sdwilsh]

Backed out due to issues folks are seeing.
http://hg.mozilla.org/mozilla-central/rev/8ad89a7a4cc0

Comment 14

[Shawn Wilsher :sdwilsh]

We'll try to take the next release.

Comment 15

[Shawn Wilsher :sdwilsh]

bug 524144 filed for 3.6.20