Hi Gil, Jacques counted 157 services with names starting with "remove" and 538 starting with "delete" . OFBiz is inconsistent here, but "delete" is more commonly used. Why make it any worse by adding another "remove"?
Thanks Paul Foxworthy On 14 August 2017 at 23:50, gil portenseigne <gil.portensei...@nereide.fr> wrote: > 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 >>>> >>>> >>>> >>> >>> >> > -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: i...@coherentsoftware.com.au
