new release: 4.2.1-RC1

sandro furieri

unread,

Nov 23, 2014, 10:34:18 AM11/23/14

to spatiali...@googlegroups.com

Mikel

unread,

Nov 23, 2014, 11:34:53 AM11/23/14

to spatiali...@googlegroups.com

Hello Sandro,

just one little thing, I discovered in SpatiaLite Gui, Windows 64-bit.
If you do a query where the resultlist has got more than 500 rows, in the older versions
there was the total number displayed.
Since 1.8.0-devel there is just 500 shown and when you switch to the second page
it is 1000 and so on.
Maybe it is a bug or a performance thing. I don't know.

Do you have an explanation for the behavior?

Otherwise many thanks for your work.

Bye Mikel

a.fu...@lqt.it

unread,

Nov 23, 2014, 12:07:52 PM11/23/14

to spatiali...@googlegroups.com

Hi Mikel,

several users recently submitted their complaints because the GUI
was perceived as being unnecessarily slow while querying huge
tables containing many millions of rows.

the cause was rather obvious to be identified; in all previous
versions the GUI displayed just 500 rows at each time, anyway a
full table-scan was performed so to keep correctly updated the
total number of rows.
and performing a full table scan on a table containing many
million rows surely required several seconds.

so in the most recent 1.8.0-devel a different strategy is now
adopted: the GUI stops the current query immediately after
retrieving the required number of rows.
the perceived time is almost instantaneous but there is no way
to discover the total number of rows effectively contained into
the target table.
the number of rows reported on the bottom of the resultset panel
now simply means "since now we've found X rows" and not necessarily
corresponds to the total number of rows stored within the table.

anyway there is a simple trick allowing to restore the traditional
behaviour; you simply have to click the "Resultset: go to last row"
button.
This will trigger a full table-scan, and will consequently update
the effective number of rows stored into the table.

bye Sandro

Mikel

unread,

Nov 23, 2014, 12:53:00 PM11/23/14

to spatiali...@googlegroups.com

Hello Sandro,

I guessed that there were a technical reason. Thank you for the detailed explanation.
Helped me to understand the why.

Best regards, Mikel.

linux...@gmail.com

unread,

Nov 26, 2014, 5:48:37 PM11/26/14

to spatiali...@googlegroups.com

Hi Sandro,

Thanks for the new release. I've got a patch for spatialite-tools 4.2.1-RC1 fixing some typos. It combines a couple of patches that have been part of the Debian package for spatialite-tools for a while.

These spelling errors were reported by the lintian QA tool as part of the package build process.

Kind Regards,

Bas

0001-Fix-several-recurring-typos.patch

linux...@gmail.com

unread,

Nov 26, 2014, 6:23:20 PM11/26/14

to spatiali...@googlegroups.com

And here is the typo patch for spatialite 4.2.1-RC1.

Kind Regards,

Bas

13-succesfully-typo.patch

Reply all

Reply to author

Forward