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

Carlo A. Bertelli (Charta s.r.l.) carlo.bertelli at gmail.com
Sun Nov 1 01:38:55 PST 2020


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>
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> a
> écrit :
>
>>
>>
>> Le jeu. 29 oct. 2020 à 15:07, Alessandro Pasotti <apasotti at gmail.com> a
>> écrit :
>>
>>> On Thu, Oct 29, 2020 at 2:59 PM Denis Rouzaud <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
>>> ItOpen:   www.itopen.it
>>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/20201101/e37ac737/attachment.html>


More information about the QGIS-Developer mailing list