Hi guys, I should say I didn't pay too much attention to the details of the topic (while it seems important). However, I just saw in Twitter from Cedric Krier, Tryton fork lead:
cedrickrier <http://twitter.com/cedrickrier>: #*openerp*</search?q=%23openerp> stock management seems brokenhttp://bit.ly/5FbxWa (expand <#>) , it was already fixed in #tryton </search?q=%23tryton> since 1.0http://bit.ly/6rV92f (expand<#> ) So the link he claims Tryton has the fix is the following: http://hg.tryton.org/hgwebdir.cgi/1.0/modules/stock/file/6165ebe6dee5/product.py#l423 Anything to fix from this? (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 https://code.launchpad.net/~openerp-community/openobject-addons/addons5.2-osv_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 <[email protected]>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 : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community-leaders > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ 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
