openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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
<albert@xxxxxxxxxxx>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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community-leaders
> More help   : https://help.launchpad.net/ListHelp
>