<div dir="ltr"><div><div>Hi Andreas, <br></div>ok, that's clear. You are right, that feature is only for the postgreSQL provider currently.<br><br></div><div>I didn't see any missing requirement in SQLITE v3 - the requirement for GPKG - maybe Matthias knows more about that. We also use GDAL provider here, so we might miss some features there and have to implement or fix things upstream. We should check that with Even Rouault who implemented it in GDAL 2.0 (see <a href="https://trac.osgeo.org/gdal/wiki/rfc54_dataset_transactions">https://trac.osgeo.org/gdal/wiki/rfc54_dataset_transactions</a>)<br><br></div><div>If we go that way, we should add it to spatialite too, but the state of the provider could make it terribly hard to do, so I would set as a prerequisite that we get rid of the current provider and rely on GDAL only. <br><br></div><div>We also have had hard time to consolidate some transactional glitches in the PG provider with SQL syntax errors and failing transactions, I expect even more work with SQLITE since it is less used and polished, and also rely on GDAL in which we probably we have <br></div><div><br></div><div>Last point to note is that at OSLANDIA we have been using a lot SQLITE - spatiaLITE to push some business logic in it (the thick database practice). It revealed way more complex to write and maintain than in postgreSQL because of SQLITE limitations. So complex that it finally revealed faster to rewrite all the logic to PG, then package an embedded / no install postgreSQL application which is launched as a process when opening a QGIS project. We called that PGLITE and is one of the reasons of getting involved in OSGEO4W packaging to easily deploy that. It is very experimental currently however. Just to say to porting the same application made with PG to a offline / on field identical application is not easy at all. <br><br></div><div>So if your use case is to have simple triggers, that would do, but if you have complex procedures, developping that is not at all a straightforward port from PG code. <br></div><div><br></div><div>That said, I would love to have that supported in QGIS!<br><br></div><div><br>Regards , <br>Régis<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-27 8:17 GMT+01:00 Andreas Neumann <span dir="ltr"><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>Hi Régis,</p>
<p>Yes - I mean the "transaction group" support. Meaning that multiple layers can be edited together. Most important issue for us: ability to link related tables to newly created features without asking the user to manually save the parent table first.</p>
<p>This all works for Postgis now, but I think not for Geopackages - right?</p>
<p>Thanks,</p>
<p>Andreas</p><div><div class="h5">
<p>On 2018-02-26 22:13, Régis Haubourg wrote:</p>
<blockquote type="cite" style="padding:0 0.4em;border-left:#1010ff 2px solid;margin:0">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi Andreas, </div>
by transaction support, you mean "transaction group" support ? The one that allows to edit all the layers in one unique transaction and evaluate triggers on the fly? <br><br></div>
If not, I'm not sure to understand what is lacking currently for your use case. <br><br></div>
Nothing is planned here however. <br><br><br></div>
Regards!</div>
Régis</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2018-02-26 13:31 GMT+01:00 Andreas Neumann <span><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>Hi,</p>
<p>We would like to see transaction support in QGIS 3x for geopackages. We want to hand out geopackages and QGIS project files, for external parties to edit data for us - without the need that the third-party has PostgreSQL installed. The projects all use relations.</p>
<p>Before we test ourselves, I thought it might make sense to ask what the status or plans are for transaction support in Geopackages?</p>
<p>Should it already be supported? If not - is someone planning to work on it?</p>
<p>Thanks for your replies,</p>
<p>Andreas</p>
</div>
<br>______________________________<wbr>_________________<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="noopener noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/qgis-developer</a><br> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noopener noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/qgis-developer</a></blockquote>
</div>
</div>
</blockquote>
<p><br></p>
</div></div></div>
</blockquote></div><br></div>