Here is a patch with a more efficient rewrite of the stock reservation algorithm. It should be much lighter in terms of time and resources, even with location numbers in the thousands.
You may want to try this patch in a test database, and tell if that works for you, and with or without side effects.
Side note: managing thousands of stock locations in the same OpenERP database indicates that you are either in a very large multi-company setup, or that a granularity level is missing in OpenERP to represent what you need (e.g. sublocations, drawers, etc.) It would be interesting (from R&D point of view) to know the situation you face, so that we could provide better features in the future :-)
I am going to upload this patch as a separate bugfix branch as well.
Hello,
Here is a patch with a more efficient rewrite of the stock reservation algorithm. It should be much lighter in terms of time and resources, even with location numbers in the thousands.
You may want to try this patch in a test database, and tell if that works for you, and with or without side effects.
Side note: managing thousands of stock locations in the same OpenERP database indicates that you are either in a very large multi-company setup, or that a granularity level is missing in OpenERP to represent what you need (e.g. sublocations, drawers, etc.) It would be interesting (from R&D point of view) to know the situation you face, so that we could provide better features in the future :-)
I am going to upload this patch as a separate bugfix branch as well.