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

[Marco Hugentobler]

Hi Bernhard

I didn't try the DataDrivenInputMask plugin yet, howerver it seems to be 
a nice tool to work with related table on db side. If an application 
module is not highly complex (e.g. needs specialised map tools and 
functions), the plugin might already do everything needed on QGIS 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

Exactly, working in a transaction would allow to remove everything cleanly.

 >Would this be in api, only available to users through plugins?

Yes, it would only be available through plugins.

Regards,
Marco

On 03.06.2014 12:28, Bernhard Ströbl wrote:
> 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
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee