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