On Fri, Feb 06, 2015 at 12:54:20PM +0100, Victor Olaya wrote: > Correct, no PK in my table. What you say sounds feasible. I will try > with another table that has a PK, and see if I can reproduce the error > or not. > > I cannot expect to have a PK in the user's table, but this is at least > a clue :-)
Victor, I've been thinking of this problem overnight and thought that maybe it could be fixed by having QGIS use UPDATE..RETURNING to update the associated key. Actually, the same approach could be used for keys that are subject to change due to triggers. If you file a ticket for the problem it will be easier to deal with it, or did you already ? --strk; > 2015-02-06 12:48 GMT+01:00 Martin Dobias <[email protected]>: > > Hi Victor > > > > On Fri, Feb 6, 2015 at 5:39 PM, Victor Olaya <[email protected]> wrote: > >> > >> > >> In the case of a PostGIS layer, when the editingStopped signal is > >> emitted, the query will return no features. The feature with id 1 is > >> no longer there, and instead there will be a feature with id equal to > >> 4. So basically it seems that a modification of a feature is really a > >> removal and then an addition, and the added feature has a different id > >> than the removed one, > > > > > > Does you table have a primary key? What is the table definition? > > > > If the postgres provider can't find a primary key, it will try to use ctid > > as the ID. Then I think what you say can happen - when updating a row, > > postgres removes the old row and appends a new one and the ctid will change. > > > > Cheers > > Martin > > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
