Double write() after creating a new statement line (one2many field)

[Olivier DOSSMANN]

Server : 6.0.0-rc2
Client : 6.0.0-rc2
Web-Client : 6.0.0-rc2
Web browsers : chromimum-browser (8.0.552.224 (68599) Ubuntu 10.04), firefox (3.6.13)
Plateform : Ubuntu 10.04 LTS

Seen on both gtk client and web client.

We have to prepare some functions in order to see the bug.

In fact, add these functions in the account module, in class account_bank_statement_line() (@end for an example) :

def create(self, cr, user, vals, context={}):
        res_id = super(account_bank_statement_line, self).create(cr, user, vals, context)
        print("CREATING an account_bank_statement_line SUCCEEDED WITH ID = %s" % res_id)
        return res_id

    def write(self, cr, user, ids, vals, context=None):
        res = super(account_bank_statement_line, self).write(cr, user, ids, vals, context)
        print("HAVE WRITTEN object %s" % self.read(cr, user, ids[0], ['id']).get('id'))
        return res

Then launch openerp-server and any client.
Go to Accounting > Bank & Cash, then click on Cash Registers.
Create a new Cashbox, save it by clicking on the Save button.
Edit it. Open the cashbox.
Now you could add some Cash Transactions. Add new statement lines.

See the server's logs.
With 2 statements lines, I just have this by updating a line :

HAVE WRITTEN object 4
HAVE WRITTEN object 4
HAVE WRITTEN object 3
HAVE WRITTEN object 4
HAVE WRITTEN object 3

Server wrote not only the object 4, but it also wrote twice all lines.

When we create a new statement line, it prints this :

CREATING an account_bank_statement_line SUCCEEDED WITH ID = 5
HAVE WRITTEN object 5
HAVE WRITTEN object 4
HAVE WRITTEN object 3
HAVE WRITTEN object 5
HAVE WRITTEN object 4
HAVE WRITTEN object 3

Is that a right behaviour ? To my mind it's useless to call create(), write(), then to call create() and write() twice for all statement lines !

Thanks in advance for any kind of explication about this ;)

[Olivier DOSSMANN (odossmann)]

Another bug seems to be similar : https://bugs.launchpad.net/openobject-client-web/+bug/699748

[xrg (xrg)]

On Thursday 06 January 2011, you wrote:
> Public bug reported:
>
> Server : 6.0.0-rc2
> Client : 6.0.0-rc2>
> We have to prepare some functions in order to see the bug.
You, not me ;)

> See the server's logs.
> With 2 statements lines, I just have this by updating a line :
>
> HAVE WRITTEN object 4
> HAVE WRITTEN object 4
>...

Well, I ran your scenario on the "trunk-pg84" server and got the explanation
quite easily.

See the attached trace (where I have removed the timestamp and numbered the
lines for the sake of clarity). In that trace, I have set debug for
"account.bank.statement.line" [1], only (not the "account.bank.statement",
though)

At line #2 we see the write command, that was sent by the Gtk client.
At line #3, quickly enough, the ORM command of line #2 gets written into the
db with an update.
Lines 4-11 compute something, I guess, for account.bank.statement.
At line #12, we see that the related, stored, field of "company_id" is getting
updated. I'm not sure if it would be easy to optimize that into the "update"
query of line #2.
At line #52, the company id of the other statement.line gets updated.
At lines #43 and #54, a small algorithm of
account/account_bank_statement.py:42 kicks in and updates the sequence
numbers, but through calling "write()".

Well, in conclusion, there is some reason we see so many commands from the
ORM. It is not about writting the fields multiple times, but about the business
logic coming back with extra data to fill the tables.

Surely, we could improve that situation [2], but I'd vote to keep the code as
is, now. In my case, I found it confusing that the bank statements keep
resetting the sequence numbers (did that a few weeks ago for my books), but
unless I discover the real reason this code is there, I won't change it.

[1] on b-q-i it is "orm account.bank.statement.line" + "debug object on"
commands.
[2] developers must go low-level and examine such traces, IMHO.