Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

To reopen a really old thread, I like the exclamation point/warning icon
with the tool tip in 2.12.  Figured I'd give some good feedback instead
of complaining ever now and then :)

Jim
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

I wonder if we could make use of the stats the query planner uses.

http://www.postgresql.org/docs/9.1/static/monitoring-stats.html

http://www.postgresql.org/docs/9.1/static/planner-stats.html

I don't know how tightly this would couple us to any single version of
postgresql though.

Jim

On 09/04/2015 02:42 AM, Andrea Peri wrote:
> Ho,
> How do qgis to analyze the table to retrieve the unique?
> A loop on every record or a SQL to count distinct ?
> 
> A.
> 
> Il 04/set/2015 08:01, "Bernhard Ströbl"  > ha scritto:
> 
> 
> 
> Am 03.09.2015 um 23:41 schrieb Sandro Santilli:
> 
> On Wed, Sep 02, 2015 at 08:48:34AM +0200, Bernhard Ströbl wrote:
> 
> Am 01.09.2015 um 17:49 schrieb Matthias Kuhn:
> 
> 
> 
> 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.
> 
> 
> It's not mandatory for a table to have a PK.
> I guess by "tables without a PK" he means table for which no PRIMARY
> KEY constraint is explicitly defined (should an UNIQUE key be
> considered equally valid?).
> 
> 
> It is not mandatory, of course, that's why I wrote "should", but
> IMHO it is very bad database design to not define one.
> There might be several UNIQUE constraints on one table but there can
> be only one PK constraint. So in case of only a UINIQUE constraint
> the table would be handled as any other without PK constraint (or
> QGIS needs to analyse how many fields have a UNIQUE constraint).
> 
> Bernhard
> 
> 
> __ Information from ESET Mail Security, version of virus
> signature database 12200 (20150904) __
> 
> The message was checked by ESET Mail Security.
> http://www.eset.com
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi Andrea,

On Fri, 04. Sep 2015 at 11:20:39 +0200, Andrea Peri wrote:
> Something like this (see image attached).

Hm, the problem seems to be that it's to much to ask a user to select one
unique key field of a view.  Doesn't this make it even worse?

Letting him select multiple columns in the selection dialog and using those to
produce a unique feature id should be a relatively small task (pktFidMap is
already there, combobox can have checkable items), but doesn't solve the
problem at hand.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Andrea Peri]

Something like this (see image attached).




2015-09-04 10:29 GMT+02:00 Jürgen E. :
> Hi Andrea,
>
> On Fri, 04. Sep 2015 at 10:18:31 +0200, Andrea Peri wrote:
>> The first is to allow a standard access to a view only readonly .
>
>
>> I complex step could be to link the field of the view to the field of a 
>> table.
>
> What for?
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

Sorry for the double email.  Also, I wonder how much we could extract
from EXPLAIN SELECT * FROM view; (alternatively EXPLAIN SELECT * FROM
view WHERE field1 = 1;) and if we could tease information out of that.

This all seems more complicated than it needs to be though.

Jim

On 09/04/2015 02:42 AM, Andrea Peri wrote:
> Ho,
> How do qgis to analyze the table to retrieve the unique?
> A loop on every record or a SQL to count distinct ?
> 
> A.
> 
> Il 04/set/2015 08:01, "Bernhard Ströbl"  > ha scritto:
> 
> 
> 
> Am 03.09.2015 um 23:41 schrieb Sandro Santilli:
> 
> On Wed, Sep 02, 2015 at 08:48:34AM +0200, Bernhard Ströbl wrote:
> 
> Am 01.09.2015 um 17:49 schrieb Matthias Kuhn:
> 
> 
> 
> 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.
> 
> 
> It's not mandatory for a table to have a PK.
> I guess by "tables without a PK" he means table for which no PRIMARY
> KEY constraint is explicitly defined (should an UNIQUE key be
> considered equally valid?).
> 
> 
> It is not mandatory, of course, that's why I wrote "should", but
> IMHO it is very bad database design to not define one.
> There might be several UNIQUE constraints on one table but there can
> be only one PK constraint. So in case of only a UINIQUE constraint
> the table would be handled as any other without PK constraint (or
> QGIS needs to analyse how many fields have a UNIQUE constraint).
> 
> Bernhard
> 
> 
> __ Information from ESET Mail Security, version of virus
> signature database 12200 (20150904) __
> 
> The message was checked by ESET Mail Security.
> http://www.eset.com
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

Explain also gives approx row counts and other info.

On September 4, 2015 9:49:52 AM EDT, Sandro Santilli  wrote:
>On Fri, Sep 04, 2015 at 08:31:39AM -0400, James Keener wrote:
>> Sorry for the double email.  Also, I wonder how much we could extract
>> from EXPLAIN SELECT * FROM view; (alternatively EXPLAIN SELECT * FROM
>> view WHERE field1 = 1;) and if we could tease information out of
>that.
>
>Information can be extracted from the result set with a LIMIT 0
>select, and I believe this is what qgis already does.
>
>You can see which tables are being addressed and whether those
>tables have a primary key, but it ain't easy to determine if
>those primary keys will appear uniquely in the output.
>
>--strk;

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Sandro Santilli]

On Fri, Sep 04, 2015 at 08:31:39AM -0400, James Keener wrote:
> Sorry for the double email.  Also, I wonder how much we could extract
> from EXPLAIN SELECT * FROM view; (alternatively EXPLAIN SELECT * FROM
> view WHERE field1 = 1;) and if we could tease information out of that.

Information can be extracted from the result set with a LIMIT 0
select, and I believe this is what qgis already does.

You can see which tables are being addressed and whether those
tables have a primary key, but it ain't easy to determine if
those primary keys will appear uniquely in the output.

--strk;
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Bernhard Ströbl]

Am 03.09.2015 um 23:41 schrieb Sandro Santilli:

On Wed, Sep 02, 2015 at 08:48:34AM +0200, Bernhard Ströbl wrote:

Am 01.09.2015 um 17:49 schrieb Matthias Kuhn:




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.


It's not mandatory for a table to have a PK.
I guess by "tables without a PK" he means table for which no PRIMARY
KEY constraint is explicitly defined (should an UNIQUE key be
considered equally valid?).



It is not mandatory, of course, that's why I wrote "should", but IMHO it 
is very bad database design to not define one.
There might be several UNIQUE constraints on one table but there can be 
only one PK constraint. So in case of only a UINIQUE constraint the 
table would be handled as any other without PK constraint (or QGIS needs 
to analyse how many fields have a UNIQUE constraint).


Bernhard


__ Information from ESET Mail Security, version of virus signature 
database 12200 (20150904) __

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


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Bernhard Ströbl]

Hi Andrea,

by reading out pg_constraint [1]
if a UNIQUE constraint is defined the uniqueness is guaranteed by the 
db, no need for QGIS to also check it.


Bernhard

[1] 
http://www.postgresql.org/docs/9.4/interactive/catalog-pg-constraint.html


Am 04.09.2015 um 08:42 schrieb Andrea Peri:

Ho,
How do qgis to analyze the table to retrieve the unique?
A loop on every record or a SQL to count distinct ?

A.

Il 04/set/2015 08:01, "Bernhard Ströbl" > ha scritto:



Am 03.09.2015 um 23:41 schrieb Sandro Santilli:

On Wed, Sep 02, 2015 at 08:48:34AM +0200, Bernhard Ströbl wrote:

Am 01.09.2015 um 17:49 schrieb Matthias Kuhn:



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.


It's not mandatory for a table to have a PK.
I guess by "tables without a PK" he means table for which no PRIMARY
KEY constraint is explicitly defined (should an UNIQUE key be
considered equally valid?).


It is not mandatory, of course, that's why I wrote "should", but
IMHO it is very bad database design to not define one.
There might be several UNIQUE constraints on one table but there can
be only one PK constraint. So in case of only a UINIQUE constraint
the table would be handled as any other without PK constraint (or
QGIS needs to analyse how many fields have a UNIQUE constraint).

Bernhard


__ Information from ESET Mail Security, version of virus
signature database 12200 (20150904) __

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


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/qgis-user





__ Information from ESET Mail Security, version of virus signature 
database 12200 (20150904) __

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


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi Sandro,

On Thu, 03. Sep 2015 at 23:44:51 +0200, Sandro Santilli wrote:
> 
> I'd note that supporting complex primary keys would also allow
> qgis to identify rows based on an expensively computed fingerprint
> of the hash of the canonical form of each and every field.
> 

As said we already support complex primary keys for tables.  But not for views
- because we don't know what the components of the key are.

Moreover the rows themselves might not even be unique.


Jürgen


-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Andrea Peri]

Ho,
How do qgis to analyze the table to retrieve the unique?
A loop on every record or a SQL to count distinct ?

A.
Il 04/set/2015 08:01, "Bernhard Ströbl"  ha
scritto:

>
>
> Am 03.09.2015 um 23:41 schrieb Sandro Santilli:
>
>> On Wed, Sep 02, 2015 at 08:48:34AM +0200, Bernhard Ströbl wrote:
>>
>>> Am 01.09.2015 um 17:49 schrieb Matthias Kuhn:
>>>
>>
>>
>> 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.
>>>
>>
>> It's not mandatory for a table to have a PK.
>> I guess by "tables without a PK" he means table for which no PRIMARY
>> KEY constraint is explicitly defined (should an UNIQUE key be
>> considered equally valid?).
>>
>>
> It is not mandatory, of course, that's why I wrote "should", but IMHO it
> is very bad database design to not define one.
> There might be several UNIQUE constraints on one table but there can be
> only one PK constraint. So in case of only a UINIQUE constraint the table
> would be handled as any other without PK constraint (or QGIS needs to
> analyse how many fields have a UNIQUE constraint).
>
> Bernhard
>
>
> __ Information from ESET Mail Security, version of virus signature
> database 12200 (20150904) __
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi Andrea,

On Fri, 04. Sep 2015 at 08:42:31 +0200, Andrea Peri wrote:
> How do qgis to analyze the table to retrieve the unique?
> A loop on every record or a SQL to count distinct ?

For vies probably yes.  And if that doesn't help, any combination of fields (up
to all fields).  And then hope that the very expensively found "key constraint"
is not ruined by data added later.

But actual constraints can be retrieved from the database.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Andrea Peri]

Hi,

I guess could be two kind of approaches alternative to the actual.

The first is to allow a standard access to a view only readonly .
Avoiding so the need for a pk field.
For who need a view writable in qgis. The approach could be to allow
in the properties of the layer in the field section to set the type PK
in the list of fields of the view.
I guess this is acceptable because s similar to the usage of it for
defining alias or hide fields from the view.


The second approach is to ask to the user when add a layer that is a
view if need editable or not. If the user ask for an add layer (view)
editable .
(Otherwise start this analysys the first time the user check the
editing button).
As kind of analysy I guess the best approach could be to do
a kind of:

select count(distinct (field1, field2)) from view;

To avoid to check for every field of the view.
A first reduction could be done using the field from tables where
there is an alphanumeric index defined (don't matter unique).

I complex step could be to link the field of the view to the field of a table.
I guess this link is not provided directly from postgres.

A.


2015-09-04 8:51 GMT+02:00 Jürgen E. :
> Hi Andrea,
>
> On Fri, 04. Sep 2015 at 08:42:31 +0200, Andrea Peri wrote:
>> How do qgis to analyze the table to retrieve the unique?
>> A loop on every record or a SQL to count distinct ?
>
> For vies probably yes.  And if that doesn't help, any combination of fields 
> (up
> to all fields).  And then hope that the very expensively found "key 
> constraint"
> is not ruined by data added later.
>
> But actual constraints can be retrieved from the database.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi Andrea,

On Fri, 04. Sep 2015 at 10:18:31 +0200, Andrea Peri wrote:
> The first is to allow a standard access to a view only readonly .

That's already the case - but it doesn't solve that various other functions
(eg. attribute table, selection) also require a unique feature id.

> select count(distinct (field1, field2)) from view;

That's already done to verify that the manual pk selection is correct and leads
to and layer insertion error, if it's not.   But that is often very expensive
and therefore is not done in the dialog.  It's even not even verified in case
"use estimated metadata" is on in the connection.
 
> I complex step could be to link the field of the view to the field of a table.

What for?

> I guess this link is not provided directly from postgres.

It is - for simple fields.  But there also are expressions (think: aggregates,
store procedures call etc.), that aren't covered.   And there information about
the base fields doesn't tell you much about the situation in the view if there
are joins - a field unique in the base table is not necessarily unique in a
join with other tables.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Sandro Santilli]

On Tue, Sep 01, 2015 at 01:15:59PM -0400, James Keener wrote:

> I'd also like to point out that the primary key need not be a single field. 
> For instance (state_fips, county_fips) could be a valid key for county-based 
> metrics. Going back to the previous question I posed, do we want to tell 
> users to conform to a single-field primary key or will qgis accept valid 
> schema designs. Again, it comes down to dev time vs the cost to the user 
> experience.


I'd note that supporting complex primary keys would also allow
qgis to identify rows based on an expensively computed fingerprint
of the hash of the canonical form of each and every field.


--strk;
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Sandro Santilli]

On Wed, Sep 02, 2015 at 08:48:34AM +0200, Bernhard Ströbl wrote:
> Am 01.09.2015 um 17:49 schrieb Matthias Kuhn:


> >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.

It's not mandatory for a table to have a PK.
I guess by "tables without a PK" he means table for which no PRIMARY
KEY constraint is explicitly defined (should an UNIQUE key be
considered equally valid?).

> >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 :-)

+1, if a full scan has to be performed, it'd be better to gather
as much information as possible from it.

> >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 :-)

Agreed, better refuse to load with a clear error message than
loading and failing later.

--strk;
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Bernhard Ströbl]

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user



___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user



___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

I guess what I'm getting at is what is it used for outside of, and not within 
qgis. Are they used for queries? (Also, ctid can change on vacuum, as such they 
can't be relied upon outside the query (with any guarantees.) How would the 
situation be different if qgis used an incremental, internal integer? It's a 
guaranteed unique value (can't be said for oid or any column without an actual 
unique constraint), it just can't be persisted (can't be said for the ctid or a 
windowed function).

As I mentioned, qgis will accept non-unique fields as the primary key for a 
view (after being loaded, I don't expect that to be checked beforehand), so 
qgis isn't attempting to store the primary key in a constrained data store? 
This is what I'm most confused about. Why am i , as a user, being (poorly) to 
give qgis the name of the pk, when a non-unique field is just as acceptable?

Jim

On September 1, 2015 12:09:28 PM EDT, Matthias Kuhn  wrote:
>On 09/01/2015 05:54 PM, James Keener wrote:
>> We also need to ask what qgis is doing with this and why we need to
>> bug the user about it at all.
>>
>> Why do we not big the user about tables without a primary key? If
>> tables can be loaded without a pk, why can't views.
>QGIS relies on feature ids for a lot of different things to
>unambiguously identify features.
>
>For tables there is a (also not optimal) ctid which can be used as
>feature id:
>http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html
>
>For views there is none (see
>http://www.postgresql.org/docs/9.1/static/rules-views.html, section
>37.2.4)
>>
>> Why can I select non-unique columns as primary keys and after loading
>> the layer get no error?
>Because a lot of things in QGIS rely on feature ids and see above why
>the fallback which exists for tables does not work for views.
>Especially - but not only - editing. See my proposal #4.
>>
>> Are these also bugs? Should I make (or find?) tickets for them?
>>
>> Jim
>>
>> On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn
>>  wrote:
>>
>> 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.
>> 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.
>>
>> -
>>
>> 3. Optional: Add a button "search suitable pk" which looks for a
>> suitable unique column.
>> 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.
>>
>> 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
>> 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Matthias Kuhn]

PS: I'm sure a pull request for compound primary keys will gladly be
merged :-)

On 09/01/2015 07:15 PM, James Keener wrote:
> I don't disagree that it's a bad practice. However, is qgis a tool
> that you work with or around? Do we want to say "your data must have X
> as part of its schema or qgis can't use it" or will qgis make the best
> it can with poor data. Honestly, being loudly opinionated is a valid
> option if the developers feel it doesn't decrease the user experience
> drastically.
>
> I'd also like to point out that the primary key need not be a single
> field. For instance (state_fips, county_fips) could be a valid key for
> county-based metrics. Going back to the previous question I posed, do
> we want to tell users to conform to a single-field primary key or will
> qgis accept valid schema designs. Again, it comes down to dev time vs
> the cost to the user experience.
>
> Jim
>
> On September 1, 2015 12:42:56 PM EDT, "Leknín Řepánek"
>  wrote:
>
> Situation with a view without unique (and indexed) key is bad database
> model, or bad query. Using window function is unefficient, but i can't
> find another way to make unique column on query with duplicities in
> records. In query without duplicities is possible to use oid (but this
> needs tables with oids), or ctid (but ctid is slow).
>
> Sorting in row_number can be defined in (ORDER BY ...). But is
> unefficient (as you say). But works well for display smaller parts of
> data (thousands of features).
>
> Materialized view can be indexed. But this is about use case and it isnt
> a "pretty solution".  
>
> Je;
>
> On Tue, Sep 01, 2015 at 11:36:53AM -0400, James Keener wrote:
>
> Please stop saying this. It's fine for certain situations, but
> it is not a permanently unique identifier for a row. It may
> change when the underlying table is altered. Sure, it's unique
> if you read the results and keep them in memory and never talk
> about it again, but qgis does that on its own already.
> Moreover querying on it is extremely inefficient. Querying
> against it forces a sequence scan on the table. Depending on
> the table and version, it could also try to materialize the
> view fully in memory before doing the scan. Jim On September
> 1, 2015 11:31:32 AM EDT, "Leknín Řepánek"
>  wrote: Workaround about primary key
> in view, i had use sever times is using window function
> "row_number() over()". It works in views and in query from
> database manager. Je; On Tue, Sep 01, 2015 at 04:09:49PM
> +0200, Sandro Santilli wrote: On Tue, Sep 01, 2015 at
> 02:37:22PM +0200, 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. Reading #11317 I
> looks to me that the reported bug was about "Add PostGIS
> Layer" not giving the user full detail of why a layer could
> not be loaded: "is an invalid layer - not loaded". In this I
> agree with Aren here: http://hub.qgis.org/issues/11317#note-6
> 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. I agree that the reported
> regression was based on the false expectation that QGIS would
> pick a primary key automatically, but in the (unlikely?) case
> a user was aware of that and properly coded the view to ensure
> primary key was first (or only) numeric the change was indeed
> a degradation of the experience. 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). There should maybe be another rule about LTS
> backports being: debatable fixes/enhancement need to be
> debated more on list ? --strk;
> 
> ━━━
> Qgis-user mailing list Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

I don't disagree that it's a bad practice. However, is qgis a tool that you 
work with or around? Do we want to say "your data must have X as part of its 
schema or qgis can't use it" or will qgis make the best it can with poor data. 
Honestly, being loudly opinionated is a valid option if the developers feel it 
doesn't decrease the user experience drastically.

I'd also like to point out that the primary key need not be a single field. For 
instance (state_fips, county_fips) could be a valid key for county-based 
metrics. Going back to the previous question I posed, do we want to tell users 
to conform to a single-field primary key or will qgis accept valid schema 
designs. Again, it comes down to dev time vs the cost to the user experience.

Jim

On September 1, 2015 12:42:56 PM EDT, "Leknín Řepánek" 
 wrote:
>Situation with a view without unique (and indexed) key is bad database
>model, or bad query. Using window function is unefficient, but i can't
>find another way to make unique column on query with duplicities in
>records. In query without duplicities is possible to use oid (but this
>needs tables with oids), or ctid (but ctid is slow).
>
>Sorting in row_number can be defined in (ORDER BY ...). But is
>unefficient (as you say). But works well for display smaller parts of
>data (thousands of features).
>
>Materialized view can be indexed. But this is about use case and it
>isnt
>a "pretty solution".  
>
>Je;
>
>On Tue, Sep 01, 2015 at 11:36:53AM -0400, James Keener wrote:
>> Please stop saying this. It's fine for certain situations, but it is
>not a
>> permanently unique identifier for a row. It may change when the
>underlying
>> table is altered. Sure, it's unique if you read the results and keep
>them in
>> memory and never talk about it again, but qgis does that on its own
>already.
>> 
>> Moreover querying on it is extremely inefficient. Querying against it
>forces a
>> sequence scan on the table. Depending on the table and version, it
>could also
>> try to materialize the view fully in memory before doing the scan.
>> 
>> Jim
>> 
>> On September 1, 2015 11:31:32 AM EDT, "Leknín Řepánek"
>>  wrote:
>> 
>> Workaround about primary key in view, i had use sever times is
>using
>> window function "row_number() over()". It works in views and in
>query
>> from database manager.
>> 
>> Je;
>> 
>> On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
>>  On Tue, Sep 01, 2015 at 02:37:22PM +0200, 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.
>> 
>>  Reading #11317 I looks to me that the reported bug was about
>>  "Add PostGIS Layer" not giving the user full detail of why a
>>  layer could not be loaded: "is an invalid layer - not
>loaded".
>>  In this I agree with Aren here:
>http://hub.qgis.org/issues/11317#note-6
>> 
>>  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.
>> 
>>  I agree that the reported regression was based on the false
>expectation
>>  that QGIS would pick a primary key automatically, but in the
>>  (unlikely?) case a user was aware of that and properly coded
>the view
>>  to ensure primary key was first (or only) numeric the change
>was
>>  indeed a degradation of the experience.
>> 
>>  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).
>> 
>>  There should maybe be another rule about LTS backports
>being:
>>  debatable fixes/enhancement need to be debated more on list
>?
>> 
>>  --strk;
>>
>━━━
>> 
>>  Qgis-user mailing
>> list
>>  Qgis-user@lists.osgeo.org
>>  http://lists.osgeo.org/mailman/listinfo/qgis-user
>>

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Matthias Kuhn]

Hi Jim,

Feature ids are used for communication with the data source, basic CRUD
operations.

* Want to change attribute X of feature F: update table set x = newvalue
where id = featureid
* Want to query a set of features? select* from table where id in (id1,
id2, id3)... (e.g. often used by plugins with selected features)
etc... you get the point.

Feature ids are used as temporary references inside qgis when using
forms, selections and tons of other things.

Ctids are definitely a bad choice (I see you read the docs :) ). But
they tend to work and are certainly more stable than anything you can
generate on a view at query time and faster as well.

QGIS does not enforce a unique column. But it expects it.
IMHO it's a question of communicating this expectation of QGIS to the
user at an appropriate time and *optionally* offering heuristics, tools
and checks to identify suitable columns (--> it all comes down to the
requirement of development time being contributed or contracted).

Unfortunately there is no simple "one-suits-all" solution to this.

Regards Matthias

On 09/01/2015 06:58 PM, James Keener wrote:
> I guess what I'm getting at is what is it used for outside of, and not
> within qgis. Are they used for queries? (Also, ctid can change on
> vacuum, as such they can't be relied upon outside the query (with any
> guarantees.) How would the situation be different if qgis used an
> incremental, internal integer? It's a guaranteed unique value (can't
> be said for oid or any column without an actual unique constraint), it
> just can't be persisted (can't be said for the ctid or a windowed
> function).
>
> As I mentioned, qgis will accept non-unique fields as the primary key
> for a view (after being loaded, I don't expect that to be checked
> beforehand), so qgis isn't attempting to store the primary key in a
> constrained data store? This is what I'm most confused about. Why am i
> , as a user, being (poorly) to give qgis the name of the pk, when a
> non-unique field is just as acceptable?
>
> Jim
>
> On September 1, 2015 12:09:28 PM EDT, Matthias Kuhn
>  wrote:
>
> On 09/01/2015 05:54 PM, James Keener wrote:
>
> We also need to ask what qgis is doing with this and why we
> need to bug the user about it at all. Why do we not big the
> user about tables without a primary key? If tables can be
> loaded without a pk, why can't views. 
>
> QGIS relies on feature ids for a lot of different things to
> unambiguously identify features.
>
> For tables there is a (also not optimal) ctid which can be used as
> feature id:
> http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html
>
> For views there is none (see
> http://www.postgresql.org/docs/9.1/static/rules-views.html, section 
> 37.2.4)
>
> Why can I select non-unique columns as primary keys and after
> loading the layer get no error? 
>
> Because a lot of things in QGIS rely on feature ids and see above why
> the fallback which exists for tables does not work for views.
> Especially - but not only - editing. See my proposal #4.
>
> Are these also bugs? Should I make (or find?) tickets for
> them? Jim On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn
>  wrote: 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. 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.
> - 3. Optional: Add a button "search suitable pk"
> which looks for a suitable unique column. 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. 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 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi James,

On Tue, 01. Sep 2015 at 08:50:27 -0400, James Keener wrote:
> At the very least, don't tell people to use ROW_NUMBER() as a primary
> key.  This is just terrible advice!

FTR I didn't suggest using row_number().

> Also, I'm running 2.10.1 and when I add a view on a table with no unique
> values, and even if I select a non-unique field as my primary key, QGIS
> will happily load the view, not complain about the cardinality of the
> "primary key" being less than the carnality of the rows, and proceed to
> draw the geometries correctly and let me select features and will show
> me the correct attributes. 

You are using "use estimated metadata"?  Otherwise QGIS should have checked if
the selected pk is actually unique.   And you will only notice that there is
something wrong when you select features that have a non unique key.

> Now, go to QGIS, select column 'a' as the "primary key".  You'll see 3
> points, and you'll be able to get the correct attribute values for each

Because the features are retrieved by geometry and not by key in identify.

Select a feature and you'll find that selecting one will select all - because
we just store that feature id 1 was selected.

And as we usually don't cache features we have nothing to tie some sort of
internally generate key to the feature.

> If tables can be used without selecting a primary key, why must views?

Because for tables we can use ctid as last resort - but not that also makes
layers readonly.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi Leknín,

On Tue, 01. Sep 2015 at 18:42:56 +0200, Leknín Řepánek wrote:
> Situation with a view without unique (and indexed) key is bad database
> model, or bad query.

Not so sure about that - you might have queries (or views) that join two or
more tables that have proper primary keys and indexed, but don't produce
a unique column of their own.

I don't think there are many assumptions you can generally make on views.

Earlier version of QGIS would deduce the primary keys of the involved tables
and offer those - but that was also nothing more than a hint of what could be
unique.



Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi James,

On Tue, 01. Sep 2015 at 13:15:59 -0400, James Keener wrote:
> I'd alo like to point out that the primary key need not be a single field.
> For instance (state_fips, county_fips) could be a valid key for county-based
> metrics. Going back to the previous question I posed, do we want to tell
> users to conform to a single-field primary key or will qgis accept valid
> schema designs. Again, it comes down to dev time vs the cost to the user
> experience.

And not all that difficult - we support that for postgresql and oracle tables.
spatialite doesn't need it, because it has an internal rowid (like postgresql's
old oid).  MSSQL does not yet support it.

That could be used for views too - but the user would still have to provide
which columns to use.  Automatically deducing the key columns from the view is
probably to expensive for real use (for that reason we don't even try to for
single columns).

But to me it still isn't that frequently requested that I'd like to jump on it
in my own time (which IIRC is what I did with the postgresql provider - both
for ctid and multicolumn keys).


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi James,

On Mon, 31. Aug 2015 at 15:05:05 -0400, James Keener wrote:
> I don't mind the behavior as much as it's entirely unclear, especially
> when the window is small and you have to scroll to see the drop down,
> what is the problem.

> There should be an error message (or even an error/warning icon with the
> tool tip saying there is on PK), along with possible remedies presented
> to the user.

Well, it's not an error (same as having to select a geometry type or SRID,
before being able to add a layer that doesn't have a 'proper' constraint).

And a tooltip is already there - although it could be more visible.

BTW the ticket for this is #11317.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Sandro Santilli]

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.

BTW: resolution of #11317 is set to "wontfix"

--strk;

On Mon, Aug 31, 2015 at 09:00:15PM +0200, Luca Lanteri wrote:
> Hi,
> 
> I noticed that this new behavior has been backported to 2.8.3.
> I think this behavior should be considered a regression because now it's
> very uncomfortable to load views, specially when I have to load many views.
> I also noticed that lot of users are confused, because they thinks that
> views doesn't work. I think the old behavior was better because it allowed
> both to choose a custom gid and to load view faster.
> Currently we decide to remain with 2.8.2.
> 
> What about reconsidering to return to the old behavior ?
> 
> Thanks
> Luca
> 
> 2015-08-06 20:58 GMT+02:00 Jürgen E. :
> 
> > Hi Randal,
> >
> > On Thu, 06. Aug 2015 at 13:53:08 -0400, Randal Hale wrote:
> > > In 2.8.x I can add the view and the Primary key is automatically
> > displayed.
> >
> > No, you're supposed to select the primary key.  In 2.8.x you also have to
> > choose from all columns, but first one is preselected.  If that happens to
> > be
> > the primary key, you're fine, but that's not always the case and hence
> > newer versions force you to actually select it.
> >
> > Jürgen
> >
> > --
> > Jürgen E. Fischer   norBIT GmbH Tel.
> > +49-4931-918175-31
> > Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> > +49-4931-918175-50
> > Software Engineer   D-26506 Norden
> > http://www.norbit.de
> > QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> >
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-user
> >
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

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@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

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

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de


signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

I don't want to reopen the ticket, as that's not my place, but I would
like to comment on it and your comment here:

> Why does QGIS need a primary key?
>
> To create (persistent) feature ids that are used for selection (and
deletion and changing of attribute or geometries - but that doesn't
apply to normal views).

While I understand from the applications POV how a single primary key
makes sense, from the databases POV querying off of ROW_NUMBER() will
force a sequence scan, which may be _extremely_ slow. While this isn't
exactly your issue, advocating a "solution" to your problem that creates
a bad user experience isn't a good idea.

At least selecting based on geometry would be able to invoke the
(likely-to-exist) index on the underlying table(s), where there is no
possible way to index row_number() and it will _always_ sequence scan.

Additionally, ROW_NUMBER() _isn't_ a pk.  If the view has no ordering
being forced (and even if there is!), then additions to the underlying
table could reörder the order of the output rows, changing ROW_NUMBER().
If you were querying against the ROW_NUMBER() column, the updated view
the _wrong_ row returned -- this is a very very bad thing!

At the very least, don't tell people to use ROW_NUMBER() as a primary
key.  This is just terrible advice!

Also, I'm running 2.10.1 and when I add a view on a table with no unique
values, and even if I select a non-unique field as my primary key, QGIS
will happily load the view, not complain about the cardinality of the
"primary key" being less than the carnality of the rows, and proceed to
draw the geometries correctly and let me select features and will show
me the correct attributes. As a user, I felt very frustrated by this
(especially because the default window size hid the dropdown to select
the pk and there was no indication at all at what was wrong!) and like I
had to jump through a hoop for the programmer's convenience, not for any
matter that actually mattered.

As a programmer, I know what you're trying to do, but since it doesn't
appear to matter anyway, what's the point.  Try this.

> [local]:5432 jim@geodata=# create table testing_mult (a int, t text);CREATE 
> TABLE
> Time: 6.248 ms
> [local]:5432 jim@geodata=# select 
> AddGeometryColumn('public','testing_mult','g',4326,'POINT', 2);
>  addgeometrycolumn  
> 
>  public.testing_mult.g SRID:4326 TYPE:POINT DIMS:2 
> (1 row)
> 
> Time: 5.349 ms
> [local]:5432 jim@geodata=# insert into testing_mult values (1, 'thingy', 
> st_geomfromtext('point(1 1)',4326 ));
> INSERT 0 1
> Time: 3.062 ms
> [local]:5432 jim@geodata=# insert into testing_mult values (1, 'this', 
> st_geomfromtext('point(1 0)',4326 ));
> INSERT 0 1
> Time: 2.865 ms
> [local]:5432 jim@geodata=# insert into testing_mult values (1, 'that', 
> st_geomfromtext('point(0 0)',4326 ));
> INSERT 0 1
> Time: 2.873 ms
> [local]:5432 jim@geodata=# create view testing_mult_view as select * from 
> testing_mult ;
> CREATE VIEW
> Time: 6.055 ms

Now, go to QGIS, select column 'a' as the "primary key".  You'll see 3
points, and you'll be able to get the correct attribute values for each

Moreover, you can load the test_multi without having to give it a pk, so
again, as a user, I'm extremely confused by inconsistent behavior,
doubly so if I didn't create the DB and don't understand what a view is.

If tables can be used without selecting a primary key, why must views?
and why must the UI be so tight-lipped?  "Select a primary key" as the
tool-tip means absolutely nothing to someone not used to databases. It
means less given that you can't see the "primary key" column in the
window with the window's default size. It means even less when someone
who understands what a primary key is seeing tables that are usable and
that don't have one.

What is the point of having the user select a "primary key" if QGIS is
accepting non-unique fields with no issue?  QGIS needs to either
complain about the lack of uniqueness, or drop forcing the user to
select one.

Jim

PS: I know this isn't the place, but the db manager gives absolutely,
positively terrible feedback about this.

On 09/01/2015 04:59 AM, Jürgen E. Fischer wrote:
> Hi James,
> 
> On Mon, 31. Aug 2015 at 15:05:05 -0400, James Keener wrote:
>> I don't mind the behavior as much as it's entirely unclear, especially
>> when the window is small and you have to scroll to see the drop down,
>> what is the problem.
> 
>> There should be an error message (or even an error/warning icon with the
>> tool tip saying there is on PK), along with possible remedies presented
>> to the user.
> 
> Well, it's not an error (same as having to select a geometry type or SRID,
> before being able to add a layer that doesn't have a 'proper' constraint).
> 
> And a tooltip is already there - although it could be more visible.
> 
> BTW the ticket for this is #11317.
> 
> 
> Jürgen
> 
> 
> 
> 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Andreas Neumann]

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Leknín Řepánek]

Situation with a view without unique (and indexed) key is bad database
model, or bad query. Using window function is unefficient, but i can't
find another way to make unique column on query with duplicities in
records. In query without duplicities is possible to use oid (but this
needs tables with oids), or ctid (but ctid is slow).

Sorting in row_number can be defined in (ORDER BY ...). But is
unefficient (as you say). But works well for display smaller parts of
data (thousands of features).

Materialized view can be indexed. But this is about use case and it isnt
a "pretty solution".  

Je;

On Tue, Sep 01, 2015 at 11:36:53AM -0400, James Keener wrote:
> Please stop saying this. It's fine for certain situations, but it is not a
> permanently unique identifier for a row. It may change when the underlying
> table is altered. Sure, it's unique if you read the results and keep them in
> memory and never talk about it again, but qgis does that on its own already.
> 
> Moreover querying on it is extremely inefficient. Querying against it forces a
> sequence scan on the table. Depending on the table and version, it could also
> try to materialize the view fully in memory before doing the scan.
> 
> Jim
> 
> On September 1, 2015 11:31:32 AM EDT, "Leknín Řepánek"
>  wrote:
> 
> Workaround about primary key in view, i had use sever times is using
> window function "row_number() over()". It works in views and in query
> from database manager.
> 
> Je;
> 
> On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
>  On Tue, Sep 01, 2015 at 02:37:22PM +0200, 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.
> 
>  Reading #11317 I looks to me that the reported bug was about
>  "Add PostGIS Layer" not giving the user full detail of why a
>  layer could not be loaded: "is an invalid layer - not loaded".
>  In this I agree with Aren here: 
> http://hub.qgis.org/issues/11317#note-6
> 
>  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.
> 
>  I agree that the reported regression was based on the false 
> expectation
>  that QGIS would pick a primary key automatically, but in the
>  (unlikely?) case a user was aware of that and properly coded the view
>  to ensure primary key was first (or only) numeric the change was
>  indeed a degradation of the experience.
> 
>  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).
> 
>  There should maybe be another rule about LTS backports being:
>  debatable fixes/enhancement need to be debated more on list ?
> 
>  --strk;
> 
> ━━━
> 
>  Qgis-user mailing
> list
>  Qgis-user@lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> ━━━
> 
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Luca Lanteri]

2015-08-06 20:58 GMT+02:00 Jürgen E. :

> Hi Randal,
>
> On Thu, 06. Aug 2015 at 13:53:08 -0400, Randal Hale wrote:
> > In 2.8.x I can add the view and the Primary key is automatically
> displayed.
>
> No, you're supposed to select the primary key.  In 2.8.x you also have to
> choose from all columns, but first one is preselected.  If that happens to
> be
> the primary key, you're fine, but that's not always the case and hence
> newer versions force you to actually select it.
>
>
Indeed I think is a good habit to organize the views to always have the gid
as the first field in order to avoid the problem of choose the right PK
column.
Now qgis already warns if the column is not suitable as a PK. Probably I
miss something but I really can't understand the improvement of the new
behavior.

Thanks for your patience and for the nice work with QGIS.
Luca

>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Sandro Santilli]

On Tue, Sep 01, 2015 at 02:37:22PM +0200, 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.

Reading #11317 I looks to me that the reported bug was about
"Add PostGIS Layer" not giving the user full detail of why a
layer could not be loaded: "is an invalid layer - not loaded".
In this I agree with Aren here: http://hub.qgis.org/issues/11317#note-6

> 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.

I agree that the reported regression was based on the false expectation
that QGIS would pick a primary key automatically, but in the
(unlikely?) case a user was aware of that and properly coded the view
to ensure primary key was first (or only) numeric the change was
indeed a degradation of the experience.

> 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).

There should maybe be another rule about LTS backports being:
debatable fixes/enhancement need to be debated more on list ?

--strk;
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Leknín Řepánek]

Workaround about primary key in view, i had use sever times is using
window function "row_number() over()". It works in views and in query
from database manager.

Je;

On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
> On Tue, Sep 01, 2015 at 02:37:22PM +0200, 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.
> 
> Reading #11317 I looks to me that the reported bug was about
> "Add PostGIS Layer" not giving the user full detail of why a
> layer could not be loaded: "is an invalid layer - not loaded".
> In this I agree with Aren here: http://hub.qgis.org/issues/11317#note-6
> 
> > 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.
> 
> I agree that the reported regression was based on the false expectation
> that QGIS would pick a primary key automatically, but in the
> (unlikely?) case a user was aware of that and properly coded the view
> to ensure primary key was first (or only) numeric the change was
> indeed a degradation of the experience.
> 
> > 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).
> 
> There should maybe be another rule about LTS backports being:
> debatable fixes/enhancement need to be debated more on list ?
> 
> --strk;
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Andreas Neumann]

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user



___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user



___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[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.
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.

-

3. Optional: Add a button "search suitable pk" which looks for a
suitable unique column.
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.

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@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>>
>>> ___
>>> Qgis-user mailing list
>>> Qgis-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

We also need to ask what qgis is doing with this and why we need to bug the 
user about it at all. 

Why do we not big the user about tables without a primary key? If tables can be 
loaded without a pk, why can't views.

Why can I select non-unique columns as primary keys and after loading the layer 
get no error?

Are these also bugs? Should I make (or find?) tickets for them?

Jim

On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn  wrote:
>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.
>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.
>
>-
>
>3. Optional: Add a button "search suitable pk" which looks for a
>suitable unique column.
>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.
>
>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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user


 ___
 Qgis-user mailing list
 Qgis-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user

>>
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>___
>Qgis-user mailing list
>Qgis-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/qgis-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

I realized I'm coming off very antagonistic and don't mean to be. I understand 
the importance of a primary key, but don't want users to be told to do anti 
patterns and non beneficial things like row_number.

I also feel that the ui should be consistent and not have surprises. Tables and 
views needed to be treated similarly, and if their not, they shouldn't be 
intermingled in the ui.

My apologizes, and I will try to write from now on with a more amiable tone.

Jim

On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn  wrote:
>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.
>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.
>
>-
>
>3. Optional: Add a button "search suitable pk" which looks for a
>suitable unique column.
>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.
>
>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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user


 ___
 Qgis-user mailing list
 Qgis-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user

>>
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>___
>Qgis-user mailing list
>Qgis-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/qgis-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Matthias Kuhn]

On 09/01/2015 05:54 PM, James Keener wrote:
> We also need to ask what qgis is doing with this and why we need to
> bug the user about it at all.
>
> Why do we not big the user about tables without a primary key? If
> tables can be loaded without a pk, why can't views.
QGIS relies on feature ids for a lot of different things to
unambiguously identify features.

For tables there is a (also not optimal) ctid which can be used as
feature id:
http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html

For views there is none (see
http://www.postgresql.org/docs/9.1/static/rules-views.html, section 37.2.4)
>
> Why can I select non-unique columns as primary keys and after loading
> the layer get no error?
Because a lot of things in QGIS rely on feature ids and see above why
the fallback which exists for tables does not work for views.
Especially - but not only - editing. See my proposal #4.
>
> Are these also bugs? Should I make (or find?) tickets for them?
>
> Jim
>
> On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn
>  wrote:
>
> 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.
> 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.
>
> -
>
> 3. Optional: Add a button "search suitable pk" which looks for a
> suitable unique column.
> 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.
>
> 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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user 
>
> 
> 
> Qgis-user mailing list 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

I'm not saying the old behaviour is correct.

I'm saying the new behavior isn't friendly to non expert users. Loading from a 
database is no more difficult than loading a shapefile in most cases. I have 
clients and students do it quite often and "windowing function" means nothing 
and "primary key" is only a vague notion.

Please don't just accept a broken ui because its something _you think_ only 
"relatively advanced" users will use.

Moving towards a solution: how would people feel about a window appearing after 
selecting a view specifically asking which field to use (if one wasn't selected 
in the initial drop down). Alternatively, moving the in-row drop down to the 
beginning of the row so that small window sizes don't cut it off, and putting a 
yellow warning on it to draw attention. 

Jim

On September 1, 2015 11:36:09 AM EDT, 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@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>>
>>> ___
>>> Qgis-user mailing list
>>> Qgis-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

Please stop saying this. It's fine for certain situations, but it is not a 
permanently unique identifier for a row.  It may change when the underlying 
table is altered. Sure, it's unique if you read the results and keep them in 
memory and never talk about it again, but qgis does that on its own already.

Moreover querying on it is extremely inefficient. Querying against it forces a 
sequence scan on the table. Depending on the table and version, it could also 
try to materialize the view fully in memory before doing the scan.

Jim

On September 1, 2015 11:31:32 AM EDT, "Leknín Řepánek" 
 wrote:
>Workaround about primary key in view, i had use sever times is using
>window function "row_number() over()". It works in views and in query
>from database manager.
>
>Je;
>
>On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
>> On Tue, Sep 01, 2015 at 02:37:22PM +0200, 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.
>> 
>> Reading #11317 I looks to me that the reported bug was about
>> "Add PostGIS Layer" not giving the user full detail of why a
>> layer could not be loaded: "is an invalid layer - not loaded".
>> In this I agree with Aren here:
>http://hub.qgis.org/issues/11317#note-6
>> 
>> > 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.
>> 
>> I agree that the reported regression was based on the false
>expectation
>> that QGIS would pick a primary key automatically, but in the
>> (unlikely?) case a user was aware of that and properly coded the view
>> to ensure primary key was first (or only) numeric the change was
>> indeed a degradation of the experience.
>> 
>> > 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).
>> 
>> There should maybe be another rule about LTS backports being:
>> debatable fixes/enhancement need to be debated more on list ?
>> 
>> --strk;
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>___
>Qgis-user mailing list
>Qgis-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/qgis-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Luca Lanteri]

Hi,

I noticed that this new behavior has been backported to 2.8.3.
I think this behavior should be considered a regression because now it's
very uncomfortable to load views, specially when I have to load many views.
I also noticed that lot of users are confused, because they thinks that
views doesn't work. I think the old behavior was better because it allowed
both to choose a custom gid and to load view faster.
Currently we decide to remain with 2.8.2.

What about reconsidering to return to the old behavior ?

Thanks
Luca

2015-08-06 20:58 GMT+02:00 Jürgen E. :

> Hi Randal,
>
> On Thu, 06. Aug 2015 at 13:53:08 -0400, Randal Hale wrote:
> > In 2.8.x I can add the view and the Primary key is automatically
> displayed.
>
> No, you're supposed to select the primary key.  In 2.8.x you also have to
> choose from all columns, but first one is preselected.  If that happens to
> be
> the primary key, you're fine, but that's not always the case and hence
> newer versions force you to actually select it.
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
> +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> +49-4931-918175-50
> Software Engineer   D-26506 Norden
> http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[James Keener]

I don't mind the behavior as much as it's entirely unclear, especially
when the window is small and you have to scroll to see the drop down,
what is the problem.

There should be an error message (or even an error/warning icon with the
tool tip saying there is on PK), along with possible remedies presented
to the user.

Jim

On 08/31/2015 03:00 PM, Luca Lanteri wrote:
> Hi,
> 
> I noticed that this new behavior has been backported to 2.8.3.
> I think this behavior should be considered a regression because now it's
> very uncomfortable to load views, specially when I have to load many
> views. I also noticed that lot of users are confused, because they
> thinks that views doesn't work. I think the old behavior was better
> because it allowed both to choose a custom gid and to load view faster.
> Currently we decide to remain with 2.8.2.
> 
> What about reconsidering to return to the old behavior ? 
> 
> Thanks
> Luca
> 
> 2015-08-06 20:58 GMT+02:00 Jürgen E. >:
> 
> Hi Randal,
> 
> On Thu, 06. Aug 2015 at 13:53:08 -0400, Randal Hale wrote:
> > In 2.8.x I can add the view and the Primary key is automatically 
> displayed.
> 
> No, you're supposed to select the primary key.  In 2.8.x you also
> have to
> choose from all columns, but first one is preselected.  If that
> happens to be
> the primary key, you're fine, but that's not always the case and hence
> newer versions force you to actually select it.
> 
> Jürgen
> 
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
> +49-4931-918175-31 
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> +49-4931-918175-50 
> Software Engineer   D-26506 Norden   
>  http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on
> FreeNode
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Randal Hale]

I noticed this on the Linux/Windows version of QGIS (2.10.1).

When adding a view in Postgresql/Postgis (9.3/2.1.3) the primary key 
(all views have primary keys) has to be selected and with a single click 
it appears. In 2.8.x I can add the view and the Primary key is 
automatically displayed. Regular tables add just fine. I've not upgraded 
anything on the database end.


There doesn't appear to be any issue with the database manager - just 
the 'add PostGIS Tables' Menu.


Bug? Enhancement? Something I need to do differently?

Windows 7 and Ubuntu 14.04
Postgres 9.3
PostGIS 2.1.3
QGIS 2.10.1

Randy

--

Randal Hale
North River Geographic Systems, Inc
http://www.northrivergeographic.com
423.653.3611 rjh...@northrivergeographic.com
twitter:rjhale http://about.me/rjhale
http://www.northrivergeographic.com/introduction-to-quantum-gis

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

[Jürgen E . Fischer]

Hi Randal,

On Thu, 06. Aug 2015 at 13:53:08 -0400, Randal Hale wrote:
 In 2.8.x I can add the view and the Primary key is automatically displayed. 

No, you're supposed to select the primary key.  In 2.8.x you also have to
choose from all columns, but first one is preselected.  If that happens to be
the primary key, you're fine, but that's not always the case and hence
newer versions force you to actually select it.

Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user