lp:~openerp-connector-core-editors/openerp-connector/7.0-connector-pg-notify-listen-experimental

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

580. By Guewen Baconnier @ Camptocamp on 2013-06-25

[ADD] experimental support of PG's NOTIFY.

Though, in multiprocess, all the processes listen at the same time and they all get the NOTIFY.
Due to the autocommit, only 1 will be able to assign the job to a worker, but they will all try...
Even more, the same process will catch them all, so at end all the jobs are enqueued in the same worker.

579. By Guewen Baconnier @ Camptocamp on 2013-06-25

[MRG] from main branch

578. By Guewen Baconnier @ Camptocamp on 2013-06-25

[CHG] multiprocessing: The Jobs workers are affected by the database being closed when they
are ran in the Cron Worker process.

Thus, when OpenERP run in multiprocess, the connector do not start job workers threads.
Instead, the new script ``openerp-connector-worker`` should be used. It spawns processes
which start the the job workers threads themselves.

This is not ideal as soon as we have to ensure that OpenERP AND the script are running.
However: it still works normally when OpenERP is not using multiprocessing and this change
allow more control on the worker processes (to implement PG's NOTIFY for instance).

577. By Guewen Baconnier @ Camptocamp on 2013-06-25

[FIX] unlink was useless here because _delete() is called when: the db is dropped, the connector module is uninstalled -> anyway we do not bother anymore of the queue_worker DB table

576. By Guewen Baconnier @ Camptocamp on 2013-06-25

[REF] reworked the workers:

* do no longer use the registries, they are not reliable, check if the connector is installed on the database names
* call the signaling methods of the registry within a session context, ensure that we use the correct registry and it is cleared if necessary
* do not store the worker on the 'queue.worker' model, it is cleared when the registry is reinitialized

This is much reliable because the worker stay alive even if a registry is rebuilt (the worker was replaced by a new one before but anyway it was not linked to the registry)

575. By Guewen Baconnier @ Camptocamp on 2013-06-24

[FIX] assignment of a job or unlink of workers can fail due to concurrent transaction -> catch the exceptions and do nothing because they are already handled by another transaction

574. By Guewen Baconnier @ Camptocamp on 2013-06-21

[FIX] obviously we won't have jobs when the select for update has failed so we have to return

573. By Guewen Baconnier @ Camptocamp on 2013-05-16

[IMP] connector.checkpoint can now be searched by the name of the related records

572. By Guewen Baconnier @ Camptocamp on 2013-05-14

[FIX] DeprecationWarning: BaseException.message has been deprecated as of python 2.6

571. By Guewen Baconnier @ Camptocamp on 2013-05-13

[IMP] add a hook in the mapper to skip child records on some conditions, when skip_convert_child returns True, the child record is skipped