QGIS » QGIS Application

after a little more code diving...

the above case will be caught by uniqueData() if and only if the tables are initialized before the layer is created. if in a dynamic situation where the tables are initialized after the layer is created, the error condition still exists.

i still think a better resolution is to catch the join and rule out any of those columns as you cannot be sure they will not one day become non-unique.

My attached bugfix allows the user to specify which column they would like to use as the primary key by filling out the added "key" data member of the QgsDataSourceURI.

The QgsPostgresProvider will do some verification on the specified column if it exists, otherwise it will do the current method of trying to find a column to use.

I think that we also need to provide this sort of UI functionality:

- when selecting tables to load, allow the user to indicate that he/she wants to select the id column manually (and be prompted for it)
- when no suitable columns are found automatically, prompt the user to choose a suitable column

In both cases, qgis should continue to check that the column contains unique data.

in 468550c6 (SVN r10658) the key column of postgres view layers is now stored to the project file and retried first on reload of the project.

Replying to [comment:6 jef]:

in 468550c6 (SVN r10658) the key column of postgres view layers is now stored to the project file and retried first on reload of the project.

in my situation, i am using the qgis library and neither the application directly nor a project file. also, the problem i was having was preventing me from loading the layer initially. it would seem, then, that it would never make it into the project file?

Replying to [comment:7 jcs]:

Replying to [comment:6 jef]:

in 468550c6 (SVN r10658) the key column of postgres view layers is now stored to the
project file and retried first on reload of the project.

in my situation, i am using the qgis library and neither the application
directly nor a project file. also, the problem i was having was preventing
me from loading the layer initially. it would seem, then, that it would
never make it into the project file?

Right. The original problem is probably still there. AFAICS your patch doesn't address that issue either. So I didn't close the bug.

<pre>
setDataSourceUri( mUri.uri() ); 
</pre>

after locating the view's key column, when there is no give column or if it turned out to be unsuitable.  Which causes the key to actually make it into the project file.

That avoids the need to go through the whole expensive key column lookup procedure again on reload and should solve the problem Andreas was reporting in http://lists.osgeo.org/pipermail/qgis-user/2009-April/005182.html

Replying to [comment:8 jef]:

Right. The original problem is probably still there. AFAICS your patch doesn't address that issue either. So I didn't close the bug.

That's correct, I gave up on the bug and took the easy way out :). Something tells me that no matter what algorithm is used to look for a unique column, a view could be constructed that breaks it. That's just my pessimistic hunch, I have no proof.

> 
<pre>
> setDataSourceUri( mUri.uri() ); 
</pre>
> 
> after locating the view's key column, when there is no give column or if it turned out to be unsuitable.  Which causes the key to actually make it into the project file.

This rev looks great, thanks for looking into this.

Can this be considered a solution to the problem? Should the ticket be left open, or can be closed?

Replying to [comment:10 pcav]:

Can this be considered a solution to the problem? Should the ticket be left open, or can be closed?

I think it can be closed.