[Erp5-dev] getMovementIndex

[Sebastien Robin]

Hi all,

There is a very strange method called getMovementIndex in
ERP5/Document/SimulationMovement.

I think it is very strange, and there is a very high chance that it is not
used at all, because the content of this method is out of date.

Does anyone know if it is unsafe to remove it ?

Seb.

[Yoshinori Okuji]

Post by Sebastien Robin
There is a very strange method called getMovementIndex in
ERP5/Document/SimulationMovement.
I think it is very strange, and there is a very high chance that it is not
used at all, because the content of this method is out of date.
Does anyone know if it is unsafe to remove it ?

IIRC, it is used to optimize the reindexing of applied rules in Coramy ERP5.
It would be better not to remove it.

YO

[Sebastien Robin]

Post by Yoshinori Okuji
IIRC, it is used to optimize the reindexing of applied rules in Coramy
ERP5. It would be better not to remove it.

Ok, I have checked to the Coramy ERP5.

It might be difficult to maintain such code. There was many zsql methods
called AppliedRule_XX and also a python script
zz_AppliedRule_updateCatalog. All that is not used any more. We are using
Applied Rules for our customer without all that stuff.

So I guess it might be very time consuming to maintain it, I think a good
optimization would be placed directly on recursiveImmediateReindexObject,
and it will benefits everywhere in ERP5 (if it is not already done).

What do you think ?

Seb.

Post by Yoshinori Okuji
YO

[Yoshinori Okuji]

Post by Sebastien Robin
So I guess it might be very time consuming to maintain it, I think a good
optimization would be placed directly on recursiveImmediateReindexObject,
and it will benefits everywhere in ERP5 (if it is not already done).

Possibly. But it is not very easy to do that.

The Right Thing to do is to use catalogObjectList of portal_catalog. But this
method assumes that all objects are indexed from scratch, that is, no update
or no conflict occurs. So it is necessary to modify catalogObjectList so that
it can update objects (probably delete and insert), and can deal with uid
duplications (like catalogObject). This will make it somewhat slower, so I
don't like this very much.

One way to avoid that performance loss is to add a parameter which says if
SQLCatalog should make sanity checks. This is feasible, but this will still
make it a bit slower, because we must add a dtml conditional into each Z SQL
Method, like this:

<dtml-if delete_before_insert>
DELETE FROM catalog WHERE ...
</dtml-if>

YO

[Jean-Paul Smets]

Post by Yoshinori Okuji

Post by Sebastien Robin
So I guess it might be very time consuming to maintain it, I think a
good optimization would be placed directly on
recursiveImmediateReindexObject, and it will benefits everywhere in
ERP5 (if it is not already done).

Possibly. But it is not very easy to do that.
The Right Thing to do is to use catalogObjectList of portal_catalog. But
this method assumes that all objects are indexed from scratch, that is,
no update or no conflict occurs. So it is necessary to modify
catalogObjectList so that it can update objects (probably delete and
insert), and can deal with uid duplications (like catalogObject). This
will make it somewhat slower, so I don't like this very much.
One way to avoid that performance loss is to add a parameter which says
if SQLCatalog should make sanity checks. This is feasible, but this will
still make it a bit slower, because we must add a dtml conditional into
<dtml-if delete_before_insert>
DELETE FROM catalog WHERE ...
</dtml-if>
YO

Baseline for me: unless you find a better and faster solution, please use /
update / maintain getMovementIndex and related scripts. It is crucial for
performance and usability of ERP5 in manufacturing related applications.

JPS.

[Jean-Paul Smets]

Post by Sebastien Robin
Hi all,
There is a very strange method called getMovementIndex in
ERP5/Document/SimulationMovement.
I think it is very strange, and there is a very high chance that it is
not used at all, because the content of this method is out of date.
Does anyone know if it is unsafe to remove it ?
Seb.

It is used. It is unsafe to remove it unless you have a better solution with
the same or better speed.

getMovementIndex provides speed optimisation for the indexation of trees of
applied rules and simulation movements. Speed was multiplied by 5 to 10 by
reindexing the whole tree of simulation rather than movements one by one.

indexing of simulation movement is then achieved through specific python
scripts and SQL methods in the SQL catalog. Those scripts first call
getMovementIndex.

JPS.