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
