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

[Bernhard Ströbl]

Hi Marco

Am 05.06.2014 08:57, schrieb Marco Hugentobler:
> Hi Bernhard
>
> I didn't try the DataDrivenInputMask plugin yet,

that's a pity :)
I just mentioned it because it addresses the same question and I had to 
deal with the same problems you do.

> 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.

well, it does not matter if your plugin has special tools or not, you 
can call the mask at any time and you can customize the mask layoutwise 
(there is a tool provided) and by adding special functions to it through 
its api methods (at the moment only buttons, but would not e hard to add 
a tool, too, because it needs subclassing anyways).

>
>  >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.

that would be nice to have

>
>  >Would this be in api, only available to users through plugins?
>
> Yes, it would only be available through plugins.

I read the discussion on your pull request but can add nothing to the 
design questions risen there.
I would love to have something like that in api in order to support 
undo/redo for my plugin thus having the mask behave like any other edit 
in QGIS.

Bernhard

>
> 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
>
>



__________ Information from ESET Mail Security, version of virus signature database 9896 (20140605) __________

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