Le 19/02/2014 08:16, Matthias Kuhn a écrit :
> Hi,
> 
> Recently there was a discussion on IRC between NathanW and EvenR
> concerning SQLite's virtual table [1]
> I think this would be a (mighty) generic approach which could also serve
> this use case. I didn't give it much deeper thoughts yet, but I must
> admit it looks promising. Basically you just register a new table with
> SQLite and implement the backend for it. This gives you all the SQLite
> power (where we even have a driver for already) and therefore database
> goodies tailor suited to runtime-generated data.

Hmmm ... sounds very interesting !
Looking for more details, I found this :
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=VirtualOGR
which is a VirtualTable driver for Spatialite giving access to OGR
sources ...
And Spatialite functions handling spatial indexes can be used on them ...
So we could imagine a VirtualQGIS virtual table driver distributed with
QGIS ...
Cool ! :)

> 
> I also had the idea of creating such tables on the fly for iterators
> spanning multiple tables (for JOIN support in queries. Providing a
> provider-independent highlevel query syntax like expressions). If we do
> this I would like to make sure that we have the possibility to get
> access to the parsed query before it is executed. This is necessary to
> be able to optimize the query for databases for which we have our own
> drivers and which support such operations natively (Think of a join of
> two possibly huge postgres tables: you don't want to join them locally).
> I haven't yet verified if this is possible or not, and can therefore not
> say if this approach fulfils the requirements.

Yes. That could be used for joins as well.
I am not sure how SQLite would handle things if you have two virtual
tables and decide to JOIN them in a query ...

> 
> There are python bindings available for virtual tables, so it may be
> possible to implement it this way [2] I think it would be good to gather
> some experience in this direction before implementing it in core. I am
> not even sure how it plays with SpatiaLite.

Thanks for pointing this out. I have to think about this further.
I like it. It also enforces the idea that a Spatialite-based format
(GeoPackage?) should be considered as the native layer format for QGIS.

-- 
Hugo Mercier
Oslandia
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to