[Qgis-developer] Editing groups of layers / edit buffer / transactions

Bernhard Ströbl bernhard.stroebl at jena.de
Tue Jun 3 03:28:49 PDT 2014


Hi Marco,

Am 03.06.2014 11:50, schrieb Marco Hugentobler:
> Hi devs
>
> In the QGEP project (https://github.com/qgep/QGEP), we are trying to
> create a waste water application module based on PostgreSQL and QGIS.
> Other examples of application modules are GIS based solutions for water,
> electicity, gas, ... So what I'm describing here is valid for a large
> number of GIS based applications.
>
> In an application module, there is usually a complex database schema
> consisting of many tables, views, triggers, foreign keys, constraints,
> sql functions. We found, that it is very difficult to do editing with
> the standard QGIS tools. In QGIS, we have an isolated edit buffer per
> layer. Once editing is stopped, the edits of a layer are commited to the
> datasource. For normal edit tasks, this is a great thing. However with
> many relations between the layers, it is almost impossile to work
> without triggering a lot of constraint violations in the database.

This is exactly for which I made the DataDrivenInputMask plugin 
(https://github.com/bstroebl/DataDrivenInputMask). The automatically 
created mask takes care of NotNull and foreign key constraints. 
Sometimes additional triggers are needed to ensure data consistency, though.

> Also
> adding or removing an object is usually done with sql functions, because
> it means changes to a lot of tables. In QGEP, we would more like to work
> within a database transaction and commit / rollback a series of changes
> at once (after all, a database snapshot can be seen as an edit buffer on
> database side).

I faced the same problem and decided on using the edit buffer but 
immediately commit when the user clicks OK, which is suboptimal as data 
in related tables (n:m relations) are commited although the user cancels 
the main mask. The transaction approach would get around this 
limitation. A general problem is that you are not able to enter data in 
a related table for new features, altough there might be work-arounds 
with sequences and transactions (I did not look into that).

>
> A possibility to cope with such a special editing situation is to bypass
> the edit buffer in QGIS and redirect all the read/write access of the
> involved database providers through one connection (but only if this
> mode is activated e.g. by a plugin, normally edit buffer and providers
> will behave like now). I've submitted a pull request about that topic
> and there was quite a long discussion about it, but without a clear
> result. Therefore I'd like to discuss in a broader context (and
> separated from any implementation issues) the idea of bypassing the edit
> buffer (in special situations) and using a backend mechanism instead
> (e.g. db transactions).

Would this be in api, only available to users through plugins? So why 
not. It would be the responsibility of the plugin developer to ensure 
the correct succession of the statements in order to not violate any 
constraints.

Bernhard

>
> What are your opinions?
>
> Regards,
> Marco
>



__________ Information from ESET Mail Security, version of virus signature database 9885 (20140603) __________

The message was checked by ESET Mail Security.
http://www.eset.com




More information about the Qgis-developer mailing list