[6.1] Sequence number_next gives invalid feedback since new implementation

[Yann Papouin]

A "new" sequence implementation named "standard" is using the pgsql built-in sequence.
The "Next Number" value is incorrect because not updated when the built-in one is ('ir_sequence_%03d').

To reproduce:

[PURCHASES] -> [Purchase Management] -> [Purchase Orders] -> [Create]: PO00001
[PURCHASES] -> [Purchase Management] -> [Purchase Orders] -> [Create]: PO00002
[PURCHASES] -> [Purchase Management] -> [Purchase Orders] -> [Create]: PO00003
[PURCHASES] -> [Purchase Management] -> [Purchase Orders] -> [Create]: PO00004

[SETTINGS] -> [Configuration] -> [Sequences & Identifiers] -> [Sequences]: Purchase Order with Next Number = 1 (should be 5)

[Olivier Dony (Odoo) (odo-openerp)]

You're right, the Postgres-backed sequence implementation does not currently update its "next number", because updating the corresponding "ir.sequence" row with the new next_number value would make it subject to the same limitations and concurrency bottlenecks as the "no_gap" implementation.

We should probably replace the next_number field with a function field that queries the Postgres sequence on-demand if the sequence is of `standard` type, and reads it from the database for "no_gap" ones (also taking care of `update` operations like it is done now).

Any contributed patches are welcome, by the way :-)

Thanks for reporting!

[Rose Anne Carpeso (roseanne)]

Is there a fix on this?

[XaRz (perecastanyer)]

At August 9th, this is still hapening and it's really annoying (6.1.1)

No way to solve this?

Regards.

[Ronald Portier (Therp) (rportier1962)]

Another problem is that if for ANY reason the write() method is invoked on the ir_sequence object, the next number and increment on the Postgres sequence are reset to whatever is left in the ir_sequence row.

So let us assume that the starting number was 10. 50 numbers have been issued from the postgres sequence (so next number should be 60). If for any reason ir_sequence number is updated, the next number will be 10 again.

[Manu (manu-tiedra)]

As Ronald Portier pointed, an update to the ir_sequence object breaks the sequence so I think this bug should be medium not low.

If for performance reasons the next number can be updated while generating a sequence number at least it should be read in the edit form so the value won't be corrupted if you save the sequence without making any changes.

Finally, this bug is opened more than 9 months. Amazing.

[Davide Corio (enlightx-deactivatedaccount)]

...and valid for 7.0 as well :)

[Cristian Salamea (ovnicraft)]

Any news about this ? its usable for production branches related to merge ?

Regards,

[Olivier Dony (Odoo) (odo-openerp)]

Ronald's fix was merged in server 7.0 at revision 4978+4979. The original merge proposal was altered a bit to update it for 7.0 and make it suitable for a stable series. For more details please see the merge proposal reviews.

The fix will automatically be forward-ported to trunk.

Thanks for reporting and for your patience!