[QGIS-Developer] Status of transaction support in Geopackages

[Régis Haubourg]

Hi Andreas,
ok, that's clear. You are right, that feature is only for the postgreSQL
provider currently.

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
https://trac.osgeo.org/gdal/wiki/rfc54_dataset_transactions)

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.

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

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.

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.

That said, I would love to have that supported in QGIS!


Regards ,
Régis



2018-02-27 8:17 GMT+01:00 Andreas Neumann <a.neumann at carto.net>:

> Hi Régis,
>
> 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.
>
> This all works for Postgis now, but I think not for Geopackages - right?
>
> Thanks,
>
> Andreas
>
> On 2018-02-26 22:13, Régis Haubourg wrote:
>
> Hi Andreas,
> 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?
>
> If not, I'm not sure to understand what is lacking currently for your use
> case.
>
> Nothing is planned here however.
>
>
> Regards!
> Régis
>
> 2018-02-26 13:31 GMT+01:00 Andreas Neumann <a.neumann at carto.net>:
>
>> Hi,
>>
>> 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.
>>
>> Before we test ourselves, I thought it might make sense to ask what the
>> status or plans are for transaction support in Geopackages?
>>
>> Should it already be supported? If not - is someone planning to work on
>> it?
>>
>> Thanks for your replies,
>>
>> Andreas
>>
>> _______________________________________________
>> 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/20180227/2bb2fdd8/attachment.html>