[Qgis-developer] Questions/Suggestion on virtual layers

Bernhard Ströbl bernhard.stroebl at jena.de
Thu Mar 3 04:22:55 PST 2016


Hi Hugo,

Am 03.03.2016 um 13:14 schrieb Hugo Mercier:
> Hi,
>
> Adding double quotes when the table name contains dots and is inserted
> from the completion dialog would help, sure. Thanks for the feedback.

I would prefer to generally add double quotes (easier to code anyways :)
>
> We can as well add something in the documentation about dots in the
> query. But this is not specific to virtual layers. The same is true for
> postgis / sqlite.

You are right but PostgreSQL e.g. is not case sensitive whereas the 
virtual layer's SQL is case sensitive (I have no idea if this is the 
same in sqlite)

>
> I'll try to look at the documentation and small usability issues listed
> in this thread soon.

thanks

Bernhard

>
> On 03/03/2016 12:16, Bernhard Ströbl wrote:
>> Hi Andreas and all,
>>
>> sorry to hijack your thread but my question is related as I am also
>> trying to evaluate the new feature virtual layer.
>>
>> My first tests resulted in QGIS freezing upon clicking "Test" or "OK"
>> (2.14.0 on Ubuntu 14.04 64 bit). It finally turned up it was the layer's
>> names containing dots (e.g. "schema.table" as they come from PostGIS).
>> Double quoting any layer and field names containing dots solved this
>> issue. However I had joins containing field names with dots, too because
>> of the prefix I used ("table.") which could not be resolved but at least
>> threw an error on testing. So I would propose to at least add a notice
>> in the tooltip that if one runs into problems, double quoting layers'
>> and fields' names might solve issues. Better would be to already have
>> them double quoted if inserted from the pop-up list.
>> Should I open a ticket?
>>
>> Very cool feature, though!
>>
>> Bernhard
>>
>>
>> Am 02.03.2016 um 17:48 schrieb Neumann, Andreas:
>>> Hi Hugo,
>>>
>>> On 2016-03-02 17:17, Hugo Mercier wrote:
>>>
>>>> Hi Andreas,
>>>>
>>>> On 02/03/2016 16:27, Neumann, Andreas wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am experimenting with the virtual layers. They are quite cool!
>>>>>
>>>>> I have some suggesions/questions:
>>>>>
>>>>> 1. It would be nice to have a preview of my query results. Currently it
>>>>> is either it works - or not. If it works, but the results are wrong
>>>>> you have to start from scratch. I would suggest that when you press
>>>>> on the test button you would not only display "No error" or the
>>>>> error message, but maybe the first 10 rows of the result.
>>>>
>>>> True.
>>>> Note that you can also create a virtual layer using the DB Manager where
>>>> it can display the first rows of a query, as it is the case for other
>>>> databases.
>>>> I am not sure to love having these two very close but slightly different
>>>> dialogs. If anyone has a better idea in terms of usability, do not
>>>> hesitate to propose :)
>>>
>>> Can one create new virtual layers in the DB manager? I know that I can
>>> do queries on existing layers and load it as a new layer - but is this
>>> the same thing like a virtual layer?
>>>
>>>>> 2. Updating the virtual layer: it would be really nice if I could
>>>>> edit/improve on my virtual layers without having to start completely
>>>>> from scratch. --> Oh - now I found out that if you select an
>>>>> existing virtual layer and then use "Layer" --> "Add Layer" --> "Add
>>>>> Virtual Layer", that you can refresh an existing virtual layer. This
>>>>> is really not obvious. I think this is more a usability issue.
>>>>
>>>> Yes ... I am more used to click on the addition icon, which makes it
>>>> more direct, but you are right, this is not perfect.
>>>
>>> ah ok - the button works as "edit" if you have the layer selected. Maybe
>>> then we should rename the tooltip from "Add Virtual Layer" to "Add or
>>> Edit Virtual Layer"
>>>
>>>> An entry in the right-click menu ?
>>>
>>> Yes - that was my first idea - to look for an entry in the layer context
>>> menu. Of course this entry should only be there if it is a virtual
>>> layer.
>>>
>>>> Edit - you can also use the drop down menu of the creation dialog to
>>>> switch between different virtual layer definitions, as mentioned by Yves
>>>
>>> yes - now I found it - thanks!
>>>
>>>> 3. it is not very obvious how you can reuse an already existing
>>>> geometry column. I discovered it by accident, that you can use
>>>> layer.geometry (regardless of the original name of the geometry
>>>> column), but I think that it is not obvious. A better hint in the
>>>> the tooltip would probably help.
>>>> Indeed it appears to be not documented.
>>>
>>> This would just require an additional sentence in  the tooltip of the
>>> Query panel, after the sentence "Any functions from SQLite or Spatialite
>>> can then be used in the query.:
>>>
>>> To add or access existing geometries of a table, you can use
>>> "tablename.geometry", regardless of original geometry column's name.
>>>
>>>> 4. Unique identifier column: If you join several tables, you often have
>>>> the issue that you need to create an artificial primary key. Could
>>>> we offer a preconfigured builtin pkey - something like a rowid  for
>>>> such cases?
>>>> Good point. An autoincremented id is already generated on the feature.
>>>> That may not be a problem to add a "rowid" column in that case.
>>>
>>> That would be cool to have.
>>>
>>>> 5. What is the exact purpose of the "Embedded Layers" where you can
>>>> add/import/remove layers? I noticed that existing layers of the
>>>> project work anyway without adding/importing them first. Is the idea
>>>> that you can work on layers that aren't in the project?
>>>> Yes it is.
>>>> You can for example embed layers from the project, save the virtual
>>>> layer to a QLR and reload it in a new project, the referenced layers
>>>> would not need to be already loaded.
>>>> There may be some documentation needed as well here.
>>>
>>> Maybe we could add another tooltip here, explaining that one can add
>>> layers that are not in the project - and that you need to "embed
>>> existing layers", if you want to save to a qlr and load it in a
>>> different project.
>>>
>>>> Should I open feature request tickets for these or are there already
>>>> plans to address one or the other of the above issues?
>>>> Unfortunately, no plan yet.
>>>> Thanks for your tests and feedback !
>>>
>>> Ok - I will open feature requests for the above, where useful.
>>>
>>> Thanks,
>>> Andreas
>>>
>>>
>>> __________ Information from ESET Mail Security, version of virus
>>> signature database 13116 (20160302) __________
>>>
>>> The message was checked by ESET Mail Security.
>>> http://www.eset.com
>>>
>>>
>>>
>>> Hi Hugo,
>>>
>>> On 2016-03-02 17:17, Hugo Mercier wrote:
>>>
>>>> Hi Andreas,
>>>>
>>>> On 02/03/2016 16:27, Neumann, Andreas wrote:
>>>>> Hi,
>>>>>
>>>>> I am experimenting with the virtual layers. They are quite cool!
>>>>>
>>>>> I have some suggesions/questions:
>>>>>
>>>>>
>>>>>
>>>>>   1. It would be nice to have a preview of my query results.
>>>>> Currently it
>>>>>      is either it works - or not. If it works, but the results are wrong
>>>>>      you have to start from scratch. I would suggest that when you press
>>>>>      on the test button you would not only display "No error" or the
>>>>>      error message, but maybe the first 10 rows of the result.
>>>>
>>>> True.
>>>> Note that you can also create a virtual layer using the DB Manager where
>>>> it can display the first rows of a query, as it is the case for other
>>>> databases.
>>>> I am not sure to love having these two very close but slightly different
>>>> dialogs. If anyone has a better idea in terms of usability, do not
>>>> hesitate to propose :)
>>> Can one create new virtual layers in the DB manager? I know that I can
>>> do queries on existing layers and load it as a new layer - but is this
>>> the same thing like a virtual layer?
>>>>
>>>>
>>>>>   2. Updating the virtual layer: it would be really nice if I could
>>>>>      edit/improve on my virtual layers without having to start
>>>>> completely
>>>>>      from scratch. --> Oh - now I found out that if you select an
>>>>>      existing virtual layer and then use "Layer" --> "Add Layer" -->
>>>>> "Add
>>>>>      Virtual Layer", that you can refresh an existing virtual layer.
>>>>> This
>>>>>      is really not obvious. I think this is more a usability issue.
>>>>
>>>> Yes ... I am more used to click on the addition icon, which makes it
>>>> more direct, but you are right, this is not perfect.
>>> ah ok - the button works as "edit" if you have the layer selected. Maybe
>>> then we should rename the tooltip from "Add Virtual Layer" to "Add or
>>> Edit Virtual Layer"
>>>>
>>>> An entry in the right-click menu ?
>>> Yes - that was my first idea - to look for an entry in the layer context
>>> menu. Of course this entry should only be there if it is a virtual layer.
>>>>
>>>>
>>>> Edit - you can also use the drop down menu of the creation dialog to
>>>> switch between different virtual layer definitions, as mentioned by Yves
>>> yes - now I found it - thanks!
>>>>
>>>>
>>>>   3. it is not very obvious how you can reuse an already existing
>>>>      geometry column. I discovered it by accident, that you can use
>>>>      layer.geometry (regardless of the original name of the geometry
>>>>      column), but I think that it is not obvious. A better hint in the
>>>>      the tooltip would probably help.
>>>> Indeed it appears to be not documented.
>>> This would just require an additional sentence in  the tooltip of the
>>> Query panel, after the sentence "Any functions from SQLite or Spatialite
>>> can then be used in the query.:
>>> To add or access existing geometries of a table, you can use
>>> "tablename.geometry", regardless of original geometry column's name.
>>>>
>>>>
>>>>   4. Unique identifier column: If you join several tables, you often have
>>>>      the issue that you need to create an artificial primary key. Could
>>>>      we offer a preconfigured builtin pkey - something like a rowid  for
>>>>      such cases?
>>>> Good point. An autoincremented id is already generated on the feature.
>>>> That may not be a problem to add a "rowid" column in that case.
>>> That would be cool to have.
>>>>
>>>>
>>>>   5. What is the exact purpose of the "Embedded Layers" where you can
>>>>      add/import/remove layers? I noticed that existing layers of the
>>>>      project work anyway without adding/importing them first. Is the idea
>>>>      that you can work on layers that aren't in the project?
>>>> Yes it is.
>>>> You can for example embed layers from the project, save the virtual
>>>> layer to a QLR and reload it in a new project, the referenced layers
>>>> would not need to be already loaded.
>>>> There may be some documentation needed as well here.
>>>>
>>> Maybe we could add another tooltip here, explaining that one can add
>>> layers that are not in the project - and that you need to "embed
>>> existing layers", if you want to save to a qlr and load it in a
>>> different project.
>>>>
>>>> Should I open feature request tickets for these or are there already
>>>> plans to address one or the other of the above issues?
>>>> Unfortunately, no plan yet.
>>>> Thanks for your tests and feedback !
>>>>
>>> Ok - I will open feature requests for the above, where useful.
>>> Thanks,
>>> Andreas
>>>
>>>
>>> __________ Information from ESET Mail Security, version of virus
>>> signature database 13116 (20160302) __________
>>>
>>> The message was checked by ESET Mail Security.
>>> http://www.eset.com
>>>
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>>
>> __________ Information from ESET Mail Security, version of virus
>> signature database 13120 (20160303) __________
>>
>> The message was checked by ESET Mail Security.
>> http://www.eset.com
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



__________ Information from ESET Mail Security, version of virus signature database 13121 (20160303) __________

The message was checked by ESET Mail Security.
http://www.eset.com




More information about the Qgis-developer mailing list