A Dimecres, 13 de gener de 2010, Ferdinand Gassauer va escriure: > Am Mittwoch 13 Januar 2010 16:55:37 schrieb Albert Cervera i Areny: > > A Dimecres, 13 de gener de 2010, Ferdinand Gassauer va escriure: > > > 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 > > > > The idea I had in mind explicitly avoided blocking other selects. Only > > other processes trying to assign the stock move should be locked, and > > all those will, of course, use SELECT FOR UPDATE. > > > > I will probably write a patch shortly and will probably use LOCK TABLE on > > a special table just because it allows reusing some existing functions. > > I hope you will only block processes which also want to assign the products > of the current picking - although this will matter only in installations > with many stock users. >
You're right, although it won't be an issue for most companies, I'll take a look and see what needs to be changed to use SELECT FOR UPDATE.. -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 _______________________________________________ Mailing list: https://launchpad.net/~openerp-community-leaders Post to : openerp-community-leaders@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community-leaders More help : https://help.launchpad.net/ListHelp