QEP 26 Support Of Virtual Layers about qgis-enhancement-proposals HOT 10 CLOSED

Alright, I've updated the description in the issue text.
That would be nice to have feedback (and proceed to the vote) quite soon if possible.
If everything goes well, the goal is to have it for the 2.14 release

from qgis-enhancement-proposals.

Hi. So ... any objections here ?

from qgis-enhancement-proposals.

+1 from me. I think it's a really needed feature that MapInfo has that we don't.

+1 Condition: It's done as a core feature and not a plugin

@nyalldawson @wonder-sk @m-kuhn thoughts?

from qgis-enhancement-proposals.

Looks good to me...

Questions:

• I do not understand what happens in serialization: what is serialized? Just the layer definition? Or the whole table is materialized to a db file?
• are the virtual layer "live" - i.e. if something is changed in the source layer, is the change propagated? (or is there some memory/disk cache that would prevent that?)
• how does it compare to OGR's virtual layer driver in terms of functionality? http://www.gdal.org/drv_vrt.html

Few notes:

• it would be useful to have a class in qgis_core library to construct/parse URIs for the provider
• it would be good to mention the QEP implies implementation of SQL parser :)

from qgis-enhancement-proposals.

I do not understand what happens in serialization: what is serialized? Just the layer definition? Or the whole table is materialized to a db file?

Yeah, it was not very clear, sorry. I've updated the text. It's only the definition that is saved.

are the virtual layer "live" - i.e. if something is changed in the source layer, is the change propagated? (or is there some memory/disk cache that would prevent that?)

Yes, the change is propagated.

how does it compare to OGR's virtual layer driver in terms of functionality ?

It is more or less the same thing, but at the QGIS level. It allows to open any QGIS layers.

it would be useful to have a class in qgis_core library to construct/parse URIs for the provider

Ok

it would be good to mention the QEP implies implementation of SQL parser :)

There is a quick mention in the "SQL syntax" section. I am not sure a SQL parser is absolutely needed. But, this is the way I found to ease the creation of a virtual layer (it detects types of columns and tables referenced in the query)

from qgis-enhancement-proposals.

Are you happy with this @wonder-sk?

from qgis-enhancement-proposals.

If there are no objections I am happy to see this approved and moved into PR+Merge stage (even though I know you already have the code mostly done)

from qgis-enhancement-proposals.

Happy too!

from qgis-enhancement-proposals.

Great, thanks ! I still have to clean the code a bit and will send a PR.

from qgis-enhancement-proposals.

@NathanW2 should this be made final now that it's implemented and merged?

from qgis-enhancement-proposals.