[Qgis-user] QGIS 2.10.1 adding PostGIS Views

Tue Sep 1 23:48:34 PDT 2015

Hi all,

I run a database with many tables and views. All views that are to be 
used in QGIS have a column suitable as key (and I never had a problem in 
creating one). Most tables and views are loaded by scripts into my 
users' QGIS, but not all. My users do not know if a relation they try to 
load is a table or a view. The current "grayed-out state" together with 
the lack of visibility of the choose-PK combo box resulted in confusion. 
The current behaviour is coherent from a database manager's point of 
view but not from a user's. I agree with Matthias and Andreas that this 
calls for an UI improvement. I like Matthias' proposal and will comment it.

Am 01.09.2015 um 17:49 schrieb Matthias Kuhn:
> Hi,
>
> I would like to second Andreas, what we need is an improvement in the UI
> to make the user aware of the problem.
>
> My proposal (please review and improve!!!!)
>
> 1. Let the user choose whatever table/view he likes. Don't disable any
> items.

+100

> 2. If there are tables without a PK open a second modal dialog with an
> explanation of the problem and offer to select a pk from a combobox.

I hope you mean "relation" not table, a table should always have a PK. 
Only case I see is when there is a PK defined on more than one column, 
but then there probably is no suitable column and the table has to be 
redesigned. Apart from that the idea is good but wouldn't we need that 
for all other cases, too: geometry type not defined, crs not defined 
(although these will not arise with proper view definition)?

>
> -------------
>
> 3. Optional: Add a button "search suitable pk" which looks for a
> suitable unique column.

yes, why not, although the label should read something like "analyze 
relation for use in QGIS" or similar (would include detection of 
geometry type and crs if needed) because if a user knows what a PK is, 
he will most probably know which field to use anyways :-)

> 4. Optional: Add a selection "read-only" to the combobox and do some
> row_number() or other black magic and warn the user with a big red
> dialog that he's about to do something very dangerous, unreliable and
> that his warranty is now very void.

-1 either load the thing properly and if that is not possible one has to 
change the view definition to make it compatible with QGIS if it is 
supposed to be used there. An average user would probably not understand 
what he accepts and complain about bad perfomrance or not being able to 
edit the layer later on. Warning messages are regarded as an annoyance 
to be accepted not to be read and understood :-)

Bernhard
>
> Best,
> Matthias
>
> On 09/01/2015 05:36 PM, Andreas Neumann wrote:
>> Hi,
>>
>> I would regard the loading of layers from a database something
>> "relatively advanced". Normally I prepare ready to use QGIS project to
>> my users who edit and query our GIS data where they don't have to
>> bother with loading layers.
>>
>> But you are correct that it can be different persons - the one who
>> creates the view and the ones who are loading them.
>>
>> You are welcome to improve the situation/GUI, but please don't go back
>> to the old behavior where it is an assumption that the first column in
>> the list is always the primary key.
>>
>> Andreas
>>
>> On 01.09.2015 14:51, James Keener wrote:
>>> Why are you assuming the user who created the view is the one using
>>> QGIS?
>>>
>>> Jim
>>>
>>> On 09/01/2015 08:50 AM, Andreas Neumann wrote:
>>>> Hi,
>>>>
>>>> I agree with Jürgen - better let the user choose the pkey column. If
>>>> the
>>>> user knows how to create a Postgis View he also knows how to select a
>>>> primary key column.
>>>>
>>>> Andreas
>>>>
>>>> On 01.09.2015 14:37, Jürgen E. Fischer wrote:
>>>>> Hi Sandro,
>>>>>
>>>>> On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
>>>>>> I agree with Luca this should have been better not backported to
>>>>>> 2.8.3.
>>>>>> Only proper bugs should be backported, and this was a (debatable)
>>>>>> GUI enhancement, as far as I can tell.
>>>>> We intend to only backport fixes and not bugs. ;)
>>>>>
>>>>> You were always supposed to select the key column - preselecting
>>>>> the first
>>>>> column was the bug (also debatable).  And #11317 is a ticket that
>>>>> demonstrates
>>>>> there were unaware users.
>>>>>
>>>>> That the first column often happens to be the primary key and and
>>>>> the combobox
>>>>> is not lexically sorted is somewhat pure luck - and unless you
>>>>> avoid having the
>>>>> key verified (using "use estimated metadata"), keeping a wrongly
>>>>> select
>>>>> column will make the layer to insert invalid.
>>>>>
>>>>> But I agree that the tooltip that you get on disabled lines (not
>>>>> only for the
>>>>> key selection, but also geometry type and srid) might not be
>>>>> visible enough
>>>>> (but that IMHO would be just a GUI enhancement).
>>>>>
>>>>>
>>>>> Jürgen
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Qgis-user mailing list
>>>>> Qgis-user at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>>
>>>>
>>>> _______________________________________________
>>>> Qgis-user mailing list
>>>> Qgis-user at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>>
>>
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
> __________ Information from ESET Mail Security, version of virus signature database 12184 (20150901) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>

__________ Information from ESET Mail Security, version of virus signature database 12188 (20150902) __________

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