Hi Jacques,
In my opinion when I read deleteWorkEffort i'm expecting an entity-auto
service, that will remove my workEffort entry from database.
In this case it's removing the workEffort and all related entity, so i
propose to rename the service to removeWorkEffortAndRelated.
This service is to be used when i really don't care about related data.
Then we could replace deleteProductionRunRoutingTask with
removeWorkEffortAndRelated service...
The question remains, should we still define a deleteWorkEffort
entity-auto service ? I'm not sure that will be useful, but that's not
costly to have one defined...
Gil
On 11/08/2017 17:21, Jacques Le Roux wrote:
Hi Nicolas, All,
Nicolas: are you speaking about deleteProductionRunRoutingTask
(OFBIZ-9568), deleteWorkEffort (OFBIZ-9185) or both ?
I think you answered only about deleteWorkEffort and then I agree.
I was also reluctant to remove it. But then we need to define what
would be it's minimal implementation.
Because as Deepak said, when you want to delete a workeffort with
relations with other entities (hence FKs); then you need to delete
those other entities before.
And in some case it can be quite hard (I try to generalise from this
case).
I wonder if a new simpler service like deleteSimpleWorkeffort would
not be appropriate. A simple workEffort would not have any relations
with any entities, else the call would be rejected by this new service.
Because generalising seems hard, even more when considering all
entities, like eg OrderHeader
see
https://cwiki.apache.org/confluence/display/OFBENDUSER/How+to+delete+tuples+added+to+test+a+setup
and also related thread https://s.apache.org/DCiI
This time I want to get to some action :D
Jacques
Le 11/08/2017 à 11:20, Nicolas Malin a écrit :
Hello Jacques,
It's a good example why I explained that delete is interesting in
some cases.
We implemented a process with template workeffort where an operator
create a production run from the templating and delete some task that
is not needed before start. In this context, I have no reason to keep
these workeffort on the database.
I'm in favor to keep these services as simple as possible and in
coherence with the create service with information that the delete
service doesn't manage all foreign key and we need prepare the delete
before. For all other case, expire will own friend :)
Nicolas
Le 10/08/2017 à 11:56, Jacques Le Roux a écrit :
Hi,
Please give your opinion on OFBIZ-9568 before I continue on OFBIZ-9185
Thanks
Jacques
