<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
QGIS is using Spatialite 4. If I execute SELECT spatialite_version() in DB Manger, I get 4.0.0.
<div><br>
</div>
<div>The problem with creating a new layer is that with SpatiaLite 4, QGIS will not load an empty table. The debug info shows:</div>
<div><span style="color: rgb(48, 48, 48); font-family: Verdana, Tahoma, Arial, sans-serif; font-size: 12px; background-color: rgb(255, 255, 255); ">Debug: src/providers/spatialite/qgsspatialiteprovider.cpp: 523: (QgsSpatiaLiteProvider) Invalid SpatiaLite layer</span></div>
<div><font color="#303030" face="Verdana, Tahoma, Arial, sans-serif"><br>
</font></div>
<div><font color="#303030" face="Verdana, Tahoma, Arial, sans-serif">The database and table appears to be created correctly. If I use SQL to insert one record with geometry into the table with DB Manager, then I can load the table to the canvas in QGIS.</font></div>
<div><font color="#303030" face="Verdana, Tahoma, Arial, sans-serif"><br>
</font></div>
<div><font color="#303030" face="Verdana, Tahoma, Arial, sans-serif">I am using OS X 10.8.3 with QGIS daily builds from Dakota Cartography and frameworks from kygnchaos. SpatiaLite 4.0 appears to work without problems in python programs I have written. The
fact that </font>SELECT spatialite_version() in<font color="#303030" face="Verdana, Tahoma, Arial, sans-serif"> the DB Manager SQL window indicates to me that DB Manger is loading the correct version of pysqlite from the kygnchaos frameworks. </font></div>
<div><font color="#303030" face="Verdana, Tahoma, Arial, sans-serif"><br>
</font></div>
<div><font color="#303030" face="Verdana, Tahoma, Arial, sans-serif">Royce<br>
</font><br>
<br>
<br>
<div>
<div>On May 22, 2013, at 5:22 AM, <a href="mailto:a.furieri@lqt.it">a.furieri@lqt.it</a> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On Tue, 21 May 2013 13:14:00 -0600, Larry Shaffer wrote:<br>
<blockquote type="cite">Is anyone using QGIS master branch with Spatialite 4.0 successfully?<br>
If Spatialite 4.0 is still not supported yet, is anyone working on it?<br>
I can get a vector layer to Save as... to a Spatialite 4.0 db, but<br>
can't create a new one.<br>
<br>
</blockquote>
<br>
<br>
On Tue, 21 May 2013 20:42:35 +0000, Cline, Royce L. wrote:<br>
<blockquote type="cite">The other issue I have had with SpatiaLite 4 is with DB Manager. DB<br>
Manager does not recognize geometry for a table in a Spatialite 4<br>
created database (new spatial metadata). Displays the same as a table<br>
without geometry. If the database was created with Spatialite 3 or<br>
converted to a version 3 database with spatialite_convert, then it<br>
will show the table as having geometry. It would appear that DB<br>
Manager is not testing whether the database containing the table is<br>
using the new or old version of the spatial metadata.<br>
<br>
</blockquote>
<br>
both issues are closely related.<br>
since many months the QGIS-spatialite data-provider has been<br>
updated so to be able to connect indifferently both spatialite<br>
v.3.x and v.4.x DB-files. any specific difference affecting the<br>
data layout for Spatial Metadata tables adopted by each version<br>
will be always silently handled in the most appropriate way<br>
by the revised data-provider.<br>
the whole process will be absolutely transparent from the end<br>
user POV.<br>
<br>
the relevant QGIS-trunk cumulative patch corresponds to commit<br>
#47097b72 [2012 November 30]<br>
<br>
anyway, simply updating the data-provider code itself isn't enough<br>
in order to effectively activate full support for v.4.0.0 DB-files:<br>
<br>
a) QGIS binaries must be absolutely built on the top of libspatialite<br>
4.0.0 (if binaries are actually built on the top of some<br>
earlier libspatialite version the whole code implementing 4.0.0<br>
support will be conditionally disabled by CMAKE)<br>
b) at run time QGIS must effectively load libspatialite 4.0.0 (or<br>
any later version)<br>
<br>
if one or the other of these two conditions aren't satisfied, then<br>
QGIS will be completely unable to access any DB-file created by<br>
libspatialite 4.0.0<br>
<br>
so the real issue is in that quite almost Linux major distros still<br>
support obsolete versions of libspatialite; the same is true for the<br>
OSGeo4W Win distro.<br>
the net result of this situation is that even building a fresh copy<br>
of QGIS-trunk starting from sources will easily produce an executable<br>
binary completely unable to support v.4.0.0 DB-files.<br>
on the other side, building QGIS-trunk after installing a custom<br>
built libspatialite-4.x will always create binaries perfectly able<br>
to access v.4.0.0 DB-files, even on Windows MSVC/OSGeo4W.<br>
<br>
-----------------<br>
<br>
the second issue (DB Manager) requires few more considerations.<br>
Spatialite (exactly as PostGIS) supports several "high-level/abstract"<br>
SQL functions allowing to correctly handle Spatial Metadata tables<br>
in the most transparent way; such an approach is obviously intended to<br>
shield against fine-grained implementation details, which can easily<br>
change from version to version.<br>
<br>
case A)<br>
if the developer always correctly invoked the expected "high level"<br>
SQL functions, then transitioning from v.3 to v.4 is expected to be<br>
a completely painless process; because in this case the underlying<br>
library will silently accommodate for any possible physical data<br>
layout difference introduced by the most recent version.<br>
<br>
case B)<br>
on the other hand, if the developer decided to completely skip<br>
using any appropriate "abstract" SQL function so to directly perform<br>
some INSERT or UPDATE statement affecting the Spatial Metadata tables,<br>
many painful transition issues should be expected to arise while<br>
transitioning to the most recent version.<br>
in this case a patient code correction action has obviously to be<br>
applied case by case.<br>
I strongly fear that this second (worst) case is the most probable<br>
scenario we can expect to face for DB Manager (and possibly for<br>
others plug-ins).<br>
<br>
bye Sandro<br>
<br>
-- <br>
Il messaggio e' stato analizzato alla ricerca di virus o<br>
contenuti pericolosi da MailScanner, ed e'<br>
risultato non infetto.<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
http://lists.osgeo.org/mailman/listinfo/qgis-developer<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>