-
-
Notifications
You must be signed in to change notification settings - Fork 442
9.0 from 8.0 #169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
9.0 from 8.0 #169
Conversation
The job will be retried after the given number of seconds if the exception is raised with a defined 'seconds' argument.
Instead of `ir.module.module`. Simplifies as we never hit the database nor have to maintain a cache. Also, it fixes an issue when we run tests directly at the installation of a module, during the tests the previous implementation was considering the module as uninstalled instead of installed. Change proposed @bealdav. Thanks! Fixes OCA#85
Check if a module is installed from the registry
Allow to define seconds and ignore retries when raising RetryableJobError
This context manager allows to execute a job function synchronously when it should normally have been delayed in a asynchronous job. This is really useful for writing tests that check the flow of a synchronisation without having to deal with the jobs execution mechanisms. It is used in the OCA/connector-magento project and ought to be used by other projects.
…o_direct Add 'mock_job_delay_to_direct' to ease tests on jobs
[FIX] Set job to failed after non-retryable OperationalError
…ribing-users [8.0][FIX] when a job fails, inactive users are added to its followers
This Postgres feature is invaluable when dealing with synchronisations, especially when importing concurrently records from a system. When we export a record, we are able to acquire a lock on the exported record to prevent 2 jobs to export it at the same time. This is different when we import a record for the first time and with several jobs running in parallel, chances are high that 2 jobs will import the same record at the same moment. The Postgres advisory lock comes handy there for they allow to acquire an application lock. Usually we'll acquire the lock at the beginning of an import (beginning of ``Importer.run()``) and we'll throw a ``RetryableJobError`` if the lock cannot be acquired so the job is retried later. The lock will remain in place until the end of the transaction. Example: - Job 1 imports Partner A - Job 2 imports Partner B - Partner A has a category X which happens not to exist yet - Partner B has a category X which happens not to exist yet - Job 1 import category X as a dependency - Job 2 import category X as a dependency Since both jobs are executed concurrently, they both create a record for category X. With this lock: - Job 1 imports Partner A, it puts a lock for this partner - Job 2 imports Partner B, it puts a lock for this partner - Partner A has a category X which happens not to exist yet - Partner B has a category X which happens not to exist yet - Job 1 import category X as a dependency, it puts a lock for this category - Job 2 import category X as a dependency, try to put a lock but can't, Job 2 is retried later, and when it is retried, it sees the category X created by Job 1 See http://topopps.com/implementing-postgres-advisory-locks/ for the article where I learned about the computation of the hash for this purpose.
Context manager to acquire Postgres advisory locks
It is no longer a context manager, because we would expect the lock to be released at the end of the 'with' statement but it lasts until the end of the transaction.
Rename try_advisory_lock to advisory_lock_or_retry
Update mailing list address
Clear environment caches and recomputations upon failures
Update index.rst
Set job back to 'pending' in case of exception
Commit c97ebbd was a frontport from 7.0. However, openerp.sql_db.dsn was changed in 8.0 in that it now returns a tuple. Extract the db_name from the returned tuple.
Fix bug introduced in c97ebbd in jobrunner
The first item contains the name of the DB such as 'odoo_db' and the second item contains 'user=gbaconnier dbname=odoo_db' which is what expects psycopg2.connect.
Fix the fix c3fefd2 :-(
…ctive user is also inactive Fix the test accordingly (odoo/odoo@328d34a)
7d099cb
to
61d665d
Compare
* In openerp.addons.connector.session.ConnectorSession: * Remove method 'search' * Remove method 'write' * Remove method 'browse' * Remove method 'read' * Remove method 'create' * Remove method 'unlink' * In openerp.addons.connector.connector.ConnectorUnit: * Remove method 'get_connector_unit_for_model' * Remove method 'get_binder_for_model' * Remove property 'environment' * In openerp.addons.connector.connector.ConnectorEnvironment: * Remove method 'set_lang' * In openerp.addons.connector.connector.connector.MetaConnectorUnit * Remove property 'model_name' * Remove class openerp.addons.connector.connector.Environment * Remove method openerp.addons.connector.connector.intall_in_connector * In openerp.addons.connector.unit.synchronizer: * Remove class 'ExportSynchronizer' * Remove class 'ImportSynchronizer' * Remove class 'DeleteSynchronizer' * Remove module openerp.addons.connector.deprecate. *
61d665d
to
34cda0e
Compare
@guewen deprecated APIs removed and rebase done |
thanks! 👍 |
👍 |
👍 |
Great work! Merging... |
Merging too... 😉 |
Oh, I thought I clicked the button... |
Is this the "Odoo connector" mentioned at http://odoo-connector.com/ for which a crowd funding campaign was run? https://www.indiegogo.com/projects/odoo-connector-odoo-magento-connector-for-odoo-9#/ I don't need the Magento part, I just need the "Odoo connector framework" for v9. |
Yes & it works like a charm. |
Migration to version 9.0