Connection to the db about qgep HOT 10 CLOSED

I thought about this, and I think that choice 1 might finally be a good idea. It is not that painful to save a manhole before creating the pipe. Btw, it is like this in topobase apparently.

Otherwise, the choice 3 from Andreas and marco sounds the best.

from qgep.

1. and 4. can be combined:
   Each db table has 2 primary keys, one is an automatically generated sequence (unique in the table), the other is a uuid (unique over all datasets). QGIS internally uses the sequence as id (including temporary negative numbers for not commited features). The db however uses the uuid for foreign keys. When adding new objects, QGEP may create the uuid.

And then the QGEP Plugin could commit the individual layers in the proper order (e.g. manhole layer before pipe layer).

from qgep.

Well, basically this is point 4. For me, in choice 1, the idea is to do nothing in qgis to replace the db job. The only drawback is to commit the manhole creation before creating a pipe. But I think this is not worth the complexity of interfacing qgis with the db.

from qgep.

I would go with option three:

I think that the uuid is a requirement in the VSA-DSS model when exporting to Interlis. Either the uuid or the interlis OID, which is a 16 character code with prefix/postfix. So why not using it in QGIS as well? It would help a lot later on when merging datasets with other communities. qt already has a class to create and use GUIDs: http://doc.qt.nokia.com/4.7/quuid.html

Marco - can you investigate if we could integrate this in QGIS core as a new data/column type and whether we could also use this in table joins?

The only drawback with GUIDs is that its is not very readable for humans ...

About option 2:
I asked Martin Dobias and he told me that it should be possible with reasonable effort to keep the edit history open after a save to the database.

from qgep.

I think that the choice of the type of primary key and the choice of method are totally distinct. We could go with uuid with choice one.

I just doubt on the interest of having something quite complex just for avoiding one save click to the user....
If we have undo redo with the Postgres provider, choice 1 might be sufficient.

Choice 2 is a little bit hazardous as we change the habits of qgis users. Things would be saved without noticing the user.

Overall I like the idea of keeping things as simple as possible and keeping the philosophy of the host software. My preference is for 1 and next for 3.

from qgep.

Marco - can you investigate if we could integrate this in QGIS core as a new data/column type and whether we could also >use this in table joins?

We could use QUuid for generation of the unique identifier (by QGEP) and pass it to postgres as a string. So no new column type should be required for QGIS (table join works also with string columns).

from qgep.

ok - thanks Marco. Is it necessary to go through a "string"? PostgreSQL seems to support UUID directly: http://www.postgresql.org/docs/current/interactive/datatype-uuid.html but it seems that it cannot generate it without an additional module. In our case, QGIS would generate the UUID.

For completeness of the discussion, here is the UUID generator module in PostgreSQL:
http://www.postgresql.org/docs/current/interactive/uuid-ossp.html

from qgep.

Are you already fixed on the idea of creating the identifier in qgis?

from qgep.

Denis: do you see a major disadvantage if we go with option 3? If not, I would use this method. As discussed, it would be in parallel with the regular "serial" based pkey, which QGIS uses until QGIS can accept other primary keys than numbers.

But the join to other tables would be based on the UUID column.

from qgep.

As I wrote, the type of connection in qgis and the data type of the primary key are distinct.

I agree on the use of UUID as pkey.
I disagree on the option 3 over option 1 because we add a software piece just to avoid a user click between the creation of the manhole and the creation of the pipe...

from qgep.