openerp-expert-framework team mailing list archive

[Cloves Almeida <cjalmeida@xxxxxxxxx>]

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