[10.0][IMP] queue_job: Don't prefetch fields when vacuum + bumpversion

[rousseldenis]

@guewen@lmignon

Did this as sometimes, the amount of jobs is huge and there is no need fetching fields.

[rousseldenis]

@guewen I bumped version as it was not done for long. But in separate commit if you disagree.

[guewen]

I was sure that the prefetch only happen the first time you access a field (other than id)?

[rousseldenis]

I will try to objective that with a test script (not in the module)

[rousseldenis]

@guewen I think you're right.
The problem is the timeout when your backlog is huge. I was inspired by odoo orderpoint runner (https://github.com/odoo/odoo/blob/10.0/addons/stock/models/procurement.py#L308) to make sets of jobs to unlink and commit.
I'm not sure of all the parts I've done, so if you have suggestions, I will implement them !

[lmignon]

@rousseldenis IMO prefetch_field is useless

[lmignon]

@rousseldenis IMO all the logic should be enclosed into a try except finally block

ifuse_new_cursor:
cr=registry(self._cr.dbname).cursor()
try:
self=self.with_env(self.env(cr=cr))
jobs=job_obj.browse(jobs_ids[:jobs_set])
jobs_ids=jobs_ids[jobs_set:]
jobs.unlink()
ifuse_new_cursor:
cr.commit()
exceptOperationalError:
ifuse_new_cursor:
cr.rollback()
raisefinally:
ifuse_new_cursor:
cr.close()

[rousseldenis]

@lmignon@guewen

[lmignon]

@rousseldenis Can you modify the changlog PLZ https://github.com/OCA/queue/blob/10.0/queue_job/README.rst#changelog

[rousseldenis]

@guewen As suggested by @lmignon, should I fill in changelog as it should includes all commits descriptions since the previous version?

P.S.: The modification has been tested on a real database.

[sbidoul]

@rousseldenis are you sure the benefit is worth the additional code complexity?
I understood you faced the issue in a real pathological situation (which could be resolved manually by a sql delete). When the vacuum cron runs regularly nobody faces the issue, even on the largest queue job delployments AFAIK.

[rousseldenis]

@sbidoul You have to handle also mail messages. So, in fact there should be multiple sql deletes.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.