Ferdinand Gassauer escreveu:
Am Mittwoch 13 Januar 2010 15:41:49 schrieb Albert Cervera i Areny:
A Dimecres, 13 de gener de 2010, Cloves Almeida va escriure:
One solution would be a select for update on picking row, which
presumably would do the same as a locking table.
You're right, we can either create a special table or use SELECT FOR UPDATE
on the same table.
To my understanding "select for update" does not prohibit concurrent reads.
if we want to make this method work - "select for update" has to be done for
all "other" open stock moves for this product which must not be updated during
the validation process of the current stock_move
From what I got from the code in stock.py, it calls _product_reserve to
get the quantity and it does so by aggregating (sum) a product quantity
on a given stock location.
PostgreSQL states that SELECT FOR UPDATE can't be used on aggregations.
I guess if we issue a simple SELECT with the same WHERE clause it would
lock a concurrent SELECT FOR UPDATE read on those rows, and that's the
behavior we want.
I didn't test it, but maybe adding the code below to stock.py:276 should
do the trick.
cr.execute("select id from stock_move where location_dest_id=%s and
location_id<>%s and product_id=%s and state='done' FOR UPDATE", (id, id,
product_id));
cr.execute("select id from stock_move where location_id=%s and
location_dest_id<>%s and product_id=%s and state in ('done', 'assigned')
FOR UPDATE", (id, id, product_id))
_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help : https://help.launchpad.net/ListHelp
