c2c-oerpscenario team mailing list archive

[xrg <xrg@xxxxxxxxx>]

Public bug reported:

Reproduce with:
(at b-q-i)
> module upgrade hr_timesheet_invoice
> module upgrade hr_timesheet_invoice

The first time, that the "test/test_hr_timesheet_invoice.yml" will try to load, at line #6 it will try to create the "account_analytic_line_developyamlforhrmodule0" entry of account.analytic.line. At line #47 (or #48 w/o my patch) that record
will be browsed and used.
At the end of the test, the cursor will rollback and never commit. 

The second time that the same test is attempted, ir.model.data will have
cached the id of the "...developyamlforhrmodule0". However, the record
of line #6 will be created at a different id. Line #47 will then bork,
because it will reference a non-existing record.

At pg84, this is reproducible too. However, if I set
"config.enable=False" (that I usually do to make it faster), the problem
disappears.

I set it low prio, because it's about tests and 2nd run of them. I
suppose intelligently cleaning the cache on a rollback could be tricky,
too.

** Affects: openobject-server
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/685171

Title:
  ir.model.data of yaml records falsely cached

Status in OpenObject Server:
  New

Bug description:
  Reproduce with:
(at b-q-i)
> module upgrade hr_timesheet_invoice
> module upgrade hr_timesheet_invoice

The first time, that the "test/test_hr_timesheet_invoice.yml" will try to load, at line #6 it will try to create the "account_analytic_line_developyamlforhrmodule0" entry of account.analytic.line. At line #47 (or #48 w/o my patch) that record
will be browsed and used.
At the end of the test, the cursor will rollback and never commit. 

The second time that the same test is attempted, ir.model.data will have cached the id of the "...developyamlforhrmodule0". However, the record of line #6 will be created at a different id. Line #47 will then bork, because it will reference a non-existing record.

At pg84, this is reproducible too. However, if I set "config.enable=False" (that I usually do to make it faster), the problem disappears.

I set it low prio, because it's about tests and 2nd run of them. I suppose intelligently cleaning the cache on a rollback could be tricky, too.