[6.1] Sequence number_next gives invalid feedback since new implementation

Bug #960201 reported by Yann Papouin on 2012-03-20
38
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Fix Released
Low
OpenERP Publisher's Warranty Team
Therp Backports (Deprecated)
Undecided
Ronald Portier (Therp)
Server-6.1
Undecided
Ronald Portier (Therp)

Bug Description

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)

Related branches

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!

Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Low
status: New → Confirmed
Rose Anne Carpeso (roseanne) wrote :

Is there a fix on this?

XaRz (perecastanyer) wrote :

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

No way to solve this?

Regards.

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.

Changed in openobject-server:
assignee: OpenERP's Framework R&D (openerp-dev-framework) → OpenERP Publisher's Warranty Team (openerp-opw)
tags: added: maintenance
Manu (manu-tiedra) wrote :

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) wrote :

...and valid for 7.0 as well :)

Cristian Salamea (ovnicraft) wrote :

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

Regards,

Changed in therp-backports:
status: New → Fix Released
assignee: nobody → Ronald Portier (Therp) (rportier1962)

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!

Changed in openobject-server:
milestone: none → 7.0
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers