WARNING: about libsqlite3 3.8.5

92 views
Skip to first unread message

sandro furieri

unread,
Jul 8, 2014, 9:17:04 AM7/8/14
to spatiali...@googlegroups.com
As you probably already know, the very recent
libsqlite3 version 3.8.5 (released on 2014-06-04)
now includes a brand new R*Tree module supporting
more advanced APIs and intended to be more efficient.

Anyway we discovered during this last week end that
the 3.8.5 R*Tree implementation introduces a
completely unexpected obnoxious side-effect.

The CheckSpatialIndex() SQL function (intended to
check a Spatial Index for full consistency) will
always fail in any case (even if the Spatial Index
is in a legitimate state) when using libsqlite 3.8.5

this issue could possibly have direct practical
consequences for several users, because e.g.
Fedora 20 already distributes 3.8.5 as its standard
libsqlite3 package.

the patched code definitely resolving this issue
has been already committed into the libspatialite
Fossil repository.

bye Sandro

Volker Fröhlich

unread,
Jul 8, 2014, 3:27:20 PM7/8/14
to spatiali...@googlegroups.com
Hey Sandro!

Can you point me to the relevant commits so I can patch the Fedora
version? Or are you planning for a new release soon?

Greetings,

Volker

a.fu...@lqt.it

unread,
Jul 8, 2014, 3:58:14 PM7/8/14
to spatiali...@googlegroups.com
https://www.gaia-gis.it/fossil/libspatialite/info/aca5fb5346


> Or are you planning for a new release soon?
>

yes, I'm going to release the final 4.2 Release Candidate
in the next few days

bye Sandro

mj10777

unread,
Jul 9, 2014, 7:51:58 AM7/9/14
to spatiali...@googlegroups.com
I have adapted the Android project to use sqlite3 3.8.5and have compiled everything with yesterdays version
- everything works well
I have adapted the Android_4.2.0.mk
- with the different version number for sqlite3
- and the spatialite directory intended for the final version
-- 'libspatialite-4.2.0' instead of 'libspatialite-4.2.0-rc1'

Mark

bye Sandro
Android_4.2.0.mk

Volker Fröhlich

unread,
Jul 29, 2014, 5:35:11 AM7/29/14
to spatiali...@googlegroups.com
I applied the following to 4.1.1 in Fedora 20:

http://pkgs.fedoraproject.org/cgit/libspatialite.git/plain/libspatialite-4.1.1-sqlite-3.8.5.patch?h=f20&id=fa11a0ac6a35f88c8d1ec42a7fdcff67942ec93a

Package version 4.1.1-3 will contain it. Please let me know if I missed
something!

Greetings,

Volker

a.fu...@lqt.it

unread,
Jul 29, 2014, 7:50:53 AM7/29/14
to spatiali...@googlegroups.com
On Tue, 29 Jul 2014 07:35:03 +0200, Volker Fröhlich wrote:
> I applied the following to 4.1.1 in Fedora 20:
>
>
> http://pkgs.fedoraproject.org/cgit/libspatialite.git/plain/libspatialite-4.1.1-sqlite-3.8.5.patch?h=f20&id=fa11a0ac6a35f88c8d1ec42a7fdcff67942ec93a
>
> Package version 4.1.1-3 will contain it. Please let me know if I
> missed something!
>

Hi Volker,

I've tested thid patch on my Fedora 20 (64 bit); looks good.

bye Sandro

Pac

unread,
Aug 18, 2014, 7:01:13 AM8/18/14
to spatiali...@googlegroups.com
Hi Sandro,

SQLite 3.8.6 was released a few days ago, and it includes a fix for a bug in the R-Tree extension (Problem with rtree tables with IN() operators or as the inner loop of a join). Hope it resolves that CheckSpatialIndex issue.

Bye,
Paco.

a.fu...@lqt.it

unread,
Aug 18, 2014, 7:17:50 AM8/18/14
to spatiali...@googlegroups.com
On Mon, 18 Aug 2014 00:01:13 -0700 (PDT), Pac wrote:
> Hi Sandro,
>
> SQLite 3.8.6 was released a few days ago [1], and it includes a fix
> for a bug in the R-Tree extension (Problem with rtree tables with
> IN()
> operators or as the inner loop of a join [2]). Hope it resolves that
> CheckSpatialIndex issue.
>
> Bye,
> Paco.
>

Hi Paco,

yes, this 3.8.6 fix restores the usual behavior supported by any
previous SQLite version except 3.8.5

anyway SpatiaLite 4.2.0 on its own already introduced an alternative
approach allowing to safely check and validate the R*Tree even
on the bugged 3.8.5

all this considered this recent 3.8.6 patch is useful just when
still continuing to use earlier versions (<= 4.1.1), but is
irrelevant/neutral when using the latest 4.2.0

bye Sandro
Reply all
Reply to author
Forward
0 new messages