<div dir="ltr">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).<div>c</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 1, 2020 at 9:58 AM Régis Haubourg <<a href="mailto:regis.haubourg@gmail.com">regis.haubourg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi, <br></div><div>+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.</div><div><br></div><div>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.<br></div><div><br></div><div>Concerning the client side caching, I'm not up to date with the potential spatialite provider enhancement. <br></div><div><br></div><div>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. <br></div><div><br></div><div>Best <br></div><div>Régis<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 29 oct. 2020 à 15:11, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 29 oct. 2020 à 15:07, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Oct 29, 2020 at 2:59 PM Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> I have a WFS-T layer with a Postgis DB behind it.<br>
> On my table, I have an insert trigger (before insert) which sets a field.<br>
> 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).<br>
><br>
> Is this expected?<br>
<br>
Yes. The features are locally cached in a SQLite layer and a newly<br>
created feature will be stored locally and not retrieve from the<br>
server.<br>
<br>
> Is there anything we can fix?<br>
<br>
Of course yes but it would require re-fetching the feature(s) after an<br>
insert or an update, I think it will slow things down.<br></blockquote><div><br></div><div>This could be done asynchronously?</div><div>It sounds like a quite common scenario (or not if nobody complained...).</div><div><br></div><div>Thanks for the answer anyway.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Besides that there is no perfect solution to server-side changes: if<br>
some other user will trigger a data change on the DB we will of course<br>
miss it anyway.<br>
<br>
<br>
> Am I doing something wrong?<br>
<br>
No.<br>
<br>
Cheers<br>
<br>
<br>
-- <br>
Alessandro Pasotti<br>
QCooperative:  <a href="http://www.qcooperative.net" rel="noreferrer" target="_blank">www.qcooperative.net</a><br>
ItOpen:   <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
</blockquote></div></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>