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

[Matthias Kuhn]

Hi devs,

Being able to use transactions has a couple of advantages for users of
databases:

 * Databases are prepared for multi user access. A transaction handles
concurrent access on DB side.
 * Immediate feedback if a constraint is violated. With the edit buffer
in QGIS, constraints are checked on commit only and updates are
partially submitted.
 * The order of actions is considered (across multiple layers).
 * Triggers are executed immediately and possible effects on other
layers are visible to QGIS.
 * Feature ID's are stable across commits.

The edit buffer on QGIS side has the following jobs (if I'm right):

 * Buffer changes (insert/delete/update) for a single layer.
 * Offer undo support.
 * Broadcast (signal) changes when they occur to the QGIS system.

As some of these items are closely related to transactions the edit
buffer cannot be used in combination with transactions. So the questions
is how it is possible to still support undo in such cases (a system with
snapshots would be a possibiliity) and how to signal things (forward
actions on client side, when they are sent to the DB / push notifications).

On another note, I would be very happy to see support for a
layer-independent edit buffer for the relations. The current solution,
where a related layer has to be switched to edit mode from an embedded
form and when you turn off edit mode from the same place the whole layer
is saved, although the context of the button in the UI suggests that
only the related features are being committed. Another problem is, that
there a PK may be generated only on commit time and creating a foreign
key pointing to an uncommitted feature can not be correctly treated, as
the layer with the foreign key may be committed before the layer where
it points to. This does not need to be done via transactions, but any
kind of multi-layer edit buffer - either project wide or on groups of
layers - would be highly welcome.

I have not yet thought about all this in very detail and there may be
still some errors in the concepts outlined in this mail, but I hope some
of my thoughts on this topic are valid and constructive. It's an
important discussion on the direction to take in order to further enable
QGIS as a powerful database frontend.

Kind regards,
Matthias

On 03.06.2014 11:50, Marco Hugentobler wrote:
> 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.
> 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).
>
> 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).
>
> What are your opinions?
>
> Regards,
> Marco
>