[QGIS-Developer] WFS-T, postgis and triggers

Bo Victor Thomsen bo.victor.thomsen at gmail.com
Mon Nov 2 00:15:46 PST 2020


Good idea -

But make it an option for the specific layers, so it's possible to turn 
it "off" or "on" depending of the situation. And "off" should be the 
default.

-- 
Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 02-11-2020 kl. 07:29 skrev Denis Rouzaud:
> But couldn't we just add an option to the layer to re-fetch the data 
> once inserted?
>
> Le dim. 1 nov. 2020 à 10:39, Carlo A. Bertelli (Charta s.r.l.) 
> <carlo.bertelli at gmail.com <mailto:carlo.bertelli at gmail.com>> a écrit :
>
>     I suppose we could benefit from the help of another Alessandro,
>     the father of Spatialite. I think he is already working on WFS3.
>     Maybe this could lead to an enhancement of libspatialite to make
>     XML/JSON sources a more interactive part of Spatialite itself or a
>     virtualwms data provider for Spatialite (like virtualpg).
>     c
>
>     On Sun, Nov 1, 2020 at 9:58 AM Régis Haubourg
>     <regis.haubourg at gmail.com <mailto:regis.haubourg at gmail.com>> wrote:
>
>         Hi,
>         +1 with Denis, this is a quite common scenario, but the
>         caching issue, combined with the good old WFS-T implementation
>         spatialite provider issues looked like a big challenge.
>
>         I think the future transactional version of WFS3 - OGC APIF
>         should speed up and simplify a lot the protocol part. On my
>         side, I was just waiting fo it to happen to raise the topic again.
>
>         Concerning the client side caching, I'm not up to date with
>         the potential spatialite provider enhancement.
>
>         Having a reliable and efficient way to edit WFS-T would be
>         really nice. But as Alessandro points out, our application
>         with a lot of database intelligence will trigger a lot of data
>         refresh in any case and we will have then some lags.
>
>         Best
>         Régis
>
>
>
>
>
>
>         Le jeu. 29 oct. 2020 à 15:11, Denis Rouzaud
>         <denis.rouzaud at gmail.com <mailto:denis.rouzaud at gmail.com>> a
>         écrit :
>
>
>
>             Le jeu. 29 oct. 2020 à 15:07, Alessandro Pasotti
>             <apasotti at gmail.com <mailto:apasotti at gmail.com>> a écrit :
>
>                 On Thu, Oct 29, 2020 at 2:59 PM Denis Rouzaud
>                 <denis.rouzaud at gmail.com
>                 <mailto:denis.rouzaud at gmail.com>> wrote:
>                 >
>                 > Hi all,
>                 >
>                 > I have a WFS-T layer with a Postgis DB behind it.
>                 > On my table, I have an insert trigger (before
>                 insert) which sets a field.
>                 > When I create a feature on this layer in QGIS, I
>                 don't get back the value of this field (I have to
>                 refresh the data, by re-opening QGIS for instance).
>                 >
>                 > Is this expected?
>
>                 Yes. The features are locally cached in a SQLite layer
>                 and a newly
>                 created feature will be stored locally and not
>                 retrieve from the
>                 server.
>
>                 > Is there anything we can fix?
>
>                 Of course yes but it would require re-fetching the
>                 feature(s) after an
>                 insert or an update, I think it will slow things down.
>
>
>             This could be done asynchronously?
>             It sounds like a quite common scenario (or not if nobody
>             complained...).
>
>             Thanks for the answer anyway.
>
>
>                 Besides that there is no perfect solution to
>                 server-side changes: if
>                 some other user will trigger a data change on the DB
>                 we will of course
>                 miss it anyway.
>
>
>                 > Am I doing something wrong?
>
>                 No.
>
>                 Cheers
>
>
>                 -- 
>                 Alessandro Pasotti
>                 QCooperative: www.qcooperative.net
>                 <http://www.qcooperative.net>
>                 ItOpen: www.itopen.it <http://www.itopen.it>
>
>             _______________________________________________
>             QGIS-Developer mailing list
>             QGIS-Developer at lists.osgeo.org
>             <mailto:QGIS-Developer at lists.osgeo.org>
>             List info:
>             https://lists.osgeo.org/mailman/listinfo/qgis-developer
>             Unsubscribe:
>             https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>         _______________________________________________
>         QGIS-Developer mailing list
>         QGIS-Developer at lists.osgeo.org
>         <mailto:QGIS-Developer at lists.osgeo.org>
>         List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>         Unsubscribe:
>         https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20201102/cc2b8954/attachment-0001.html>


More information about the QGIS-Developer mailing list