A Dimecres, 13 de gener de 2010, Raphaël Valyi va escriure: > So the link he claims Tryton has the fix is the following: > http://hg.tryton.org/hgwebdir.cgi/1.0/modules/stock/file/6165ebe6dee5/produ > ct.py#l423 > > Anything to fix from this?
Yes, I know they fixed that already. The thing is that they locked the whole table and we're trying to avoid that. > (BTW, Albert we will soon reply to your osv_memory wizard refactoring > concern, we started working on this too and got stuck too with some > framework limitations, I hope I can comment soon, Tiny seems interested in > fixing it too; we almost refactored the invoice on picking wizard on that > branch as an example That's another thing that Tryton already has solved... > https://code.launchpad.net/~openerp-community/openobject-addons/addons5.2-o > sv_mem-wizards. We are currently busy polishing new Kettle plugin giving > access to the > whole OpenERP API via JRuby + OOOR, we believe it will be a revolutions for > OpenERP integration; blog post coming soon). > > > Raphaël Valyi > http://www.akretion.com > > > On Wed, Jan 13, 2010 at 3:16 PM, Albert Cervera i Areny > > <alb...@nan-tic.com>wrote: > > 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 > -- 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
