[Qgis-developer] guestimating plug-in dev time?
Bernhard Ströbl
bernhard.stroebl at jena.de
Mon Jan 19 04:29:15 PST 2015
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.sk at gmail.com
>> <mailto:wonder.sk at 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.cura at gmail.com
>> <mailto:remi.cura at 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.sk at gmail.com
>> <mailto:wonder.sk at 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.cura at gmail.com <mailto:remi.cura at 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 at lists.osgeo.org
>> <mailto:Qgis-developer at 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
More information about the Qgis-developer
mailing list