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@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
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
