I also have a lot of experience with a large number of users (around 15) editing a central database with PostGIS. No problems there.
Remi, the development time for this would be around a day. If you wish to outsource that job, I have some experience with QGIS Plugins and I could develop that for you. George On Mon, Jan 19, 2015 at 10:29 AM, Bernhard Ströbl <bernhard.stro...@jena.de> wrote: > Hi Andreas, > > I do not think that multi-core rendering is the issue here as Remi > mentions to have experienced crashes since QGIS 1.8. > > Remi, > I am using QGIS with Postgres/PostGIS with some dozens of users on a > central database _without_ any issues in QGIS (except the multi-core issue > Andreas mentioned). So do share your problems together with relevent parts > of your data base so they can beanalyzed. > > Bernhard > > Am 19.01.2015 13:19, schrieb Andreas Neumann: > >> Hi Remi, >> >> Regarding crashes with Postgis: do you have multithreading with a lot of >> CPU cores active? I am experiencing crashes if more than 2 cores are >> active. Try limiting to 2 CPU cores and see if this helps. >> >> Still trying to investigate this issue with the devs. >> >> Besides the above issue, editing with Postgis works stable for me - >> certainly not as many crashes as you say you have. >> >> Please do not ignore the crashes but try to report them so that the devs >> can do something about it. >> >> Andreas >> >> On 19.01.2015 11:57, Rémi Cura wrote: >> >>> I think a more global solution is possible. >>> After all when you load a postgis layer in qgis, if somebody else >>> changes it, the view is not refreshed, which is annoying (and >>> sometimes dangerous because you may edit old data). >>> >>> It would be easy to ad this (which would also work for my case) using >>> the LISTEN / NOTIFY feature of postgres. >>> >>> Basically when selecting a table as a new qgis layer, you >>> automatically add a triger to it. >>> The trigger will be fired at any change (create/delete/update). >>> The trigger would simply send a message to qgis via NOTIFY. >>> example : "NOTIFY qgis_change_XXXX ;", where XXXX is a unique id. >>> Of course qgis would be listening, which is very simple in python >>> (import psycopg2; >>> conn = psycopg.connect(my_database_string) >>> conn.autocommit(1) >>> curs = conn.cursor() >>> curs.execute("LISTEN qgis_change_XXXX;")) >>> >>> Of course one would need a mechanism to remove this trigger when not >>> necessary (for instance, name the channel "qgis_change_/time_stamp/", >>> delete channel too old automatically, and change channel periodically >>> (20 in for instance)). >>> >>> I don't know if from a security point of view it would be possibe >>> tough (would require the permission to create a trigger). >>> I don't know if typical qgis user have the right to create trigger on >>> database they use. >>> >>> I use a lot of different version of QGIS and I can guarantee at least >>> a dozen crash a day with version 1.8 to 2.3, >>> plus pending transaction with postgis whenever the crash occurs. >>> I'm installing 2.6 to see if postgis layers are less fragile right now ^^ >>> >>> Cheers, >>> Rémi-C >>> >>> 2015-01-19 11:29 GMT+01:00 Martin Dobias <wonder...@gmail.com >>> <mailto:wonder...@gmail.com>>: >>> >>> I see - indeed QGIS would need to do quite some database >>> inspection to understand that layer A and layer B are related. >>> This should be however also easy to address in a custom plugin. >>> >>> It is surprising to me that you say PostGIS layers are fragile in >>> QGIS - they are very commonly used by lots of people and we >>> haven't heard about crashes in the issue tracker. If you do >>> experience crashes please consider filing reports on hub.qgis.org >>> <http://hub.qgis.org> with instructions on how to replicate them. >>> >>> Regards >>> Martin >>> >>> >>> On Mon, Jan 19, 2015 at 5:18 PM, Rémi Cura <remi.c...@gmail.com >>> <mailto:remi.c...@gmail.com>> wrote: >>> >>> Thanks Martin, >>> one day to several days feel like a very reasonnable order of >>> magnitude. >>> >>> QGis is not refreshing the view because when editing layer A >>> the postgis data base automatically also edit layer B. >>> I don't think qgis has a mechanism of tracking dbchanges (it >>> would be possible tough). >>> Morevover PostGIS layer are still "fragile" in qgis (crashes >>> often). >>> >>> Thanks for the help, >>> Cheers >>> Rémi-C >>> >>> 2015-01-19 10:56 GMT+01:00 Martin Dobias <wonder...@gmail.com >>> <mailto:wonder...@gmail.com>>: >>> >>> Hi Remi >>> >>> Such plugin should be quite easy to write - I would assume >>> up to one day of work for an experienced pyqgis developer. >>> For a newcomer it may take few more days to get familiar >>> with the API, tools, environment and so on. >>> >>> For the refresh of rendering after geometry editing - that >>> should work out of the box and I would consider it a bug >>> if it does not. >>> >>> Regards >>> Martin >>> >>> >>> On Mon, Jan 19, 2015 at 3:16 PM, Rémi Cura >>> <remi.c...@gmail.com <mailto:remi.c...@gmail.com>> wrote: >>> >>> Hello dear list. >>> I'm usually active on the postgis or postgres list, >>> but today I would like to ask a question regarding dev >>> time. >>> >>> In your opinion, >>> How much time would be needed to write a plugin for >>> multiple versions of qgis (2.2 to current 2.6) doing 3 >>> simple things : >>> - auto commit the edition of geometry when in edition >>> mode (no need to click on save changes each time) >>> - force refresh of rendering after edition of a geometry >>> - every camera changes (zoom or position), send a sql >>> query containing user name and geometry of view (a >>> rectangle in wkt for instance). >>> >>> I can estimate this at my poor qgis-dev level, but I >>> would like to have the timing for an expert qgis dev. >>> >>> Many thanks, >>> >>> Remi-C >>> >>> _______________________________________________ >>> Qgis-developer mailing list >>> Qgis-developer@lists.osgeo.org >>> <mailto:Qgis-developer@lists.osgeo.org> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>> >>> >>> >>> >>> >>> >>> > > __________ Information from ESET Mail Security, version of virus signature > database 11036 (20150119) __________ > > 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 > -- George R. C. Silva SIGMA Consultoria ---------------------------- http://www.consultoriasigma.com.br/
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer