Re: Keep deleteProductionRunRoutingTask?

2017-08-24 Thread Jacques Le Roux 

Thanks Paul, Gil,

If it was not a so big move, we could even rename all remove into delete, but 
forget it ;)

Jacques


Le 24/08/2017 à 09:08, gil portenseigne a écrit :

Hi Paul,

You are right, deleteWorkEffortAndRelated will suit perfectly :)

Thanks for your feedback

Gil


On 24/08/2017 05:38, Paul Foxworthy wrote:

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 
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

Re: Keep deleteProductionRunRoutingTask?

2017-08-24 Thread gil portenseigne 

Hi Paul,

You are right, deleteWorkEffortAndRelated will suit perfectly :)

Thanks for your feedback

Gil


On 24/08/2017 05:38, Paul Foxworthy wrote:

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 
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

Re: Keep deleteProductionRunRoutingTask?

2017-08-23 Thread Paul Foxworthy 
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 
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

Re: Keep deleteProductionRunRoutingTask?

2017-08-14 Thread Jacques Le Roux 

Thanks Gil,

Inline


Le 14/08/2017 à 15:50, gil portenseigne a écrit :

Hi Jacques,

In my opinion when I read deleteWorkEffort i'm expecting an entity-auto 
service, that will remove my workEffort entry from database.

+1



In this case it's removing the workEffort and all related entity, so i propose 
to rename the service to removeWorkEffortAndRelated.

+1



This service is to be used when i really don't care about related data.

deleteWorkEffort indeed, misnamed



Then we could replace deleteProductionRunRoutingTask with 
removeWorkEffortAndRelated service...


Makes sense



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...

It would fail most of the time which is misleading.
But I understand Nicolas's POV and I guess we need to rather test at service 
start if FKs exist and return a clear  error message when they exist .

Jacques



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

Re: Keep deleteProductionRunRoutingTask?

2017-08-14 Thread gil portenseigne 

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

Re: Keep deleteProductionRunRoutingTask?

2017-08-11 Thread Jacques Le Roux 

Also for beginners we have this advice in FAQ...

https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-obsolete

Jacques


Le 11/08/2017 à 17:21, Jacques Le Roux a écrit :

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

Re: Keep deleteProductionRunRoutingTask?

2017-08-11 Thread Jacques Le Roux 

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

Re: Keep deleteProductionRunRoutingTask?

2017-08-11 Thread Nicolas Malin 

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

Re: Keep deleteProductionRunRoutingTask?

2017-08-10 Thread Vaibhav Jain 
Hello Jacques,

Just for easy reference

>>Please give your opinion on OFBIZ-9568
before I continue on
OFBIZ-9185 

Thanks & Regards

Vaibhav Jain
Hotwax Systems,
vaibhav.j...@hotwaxsystems.com

On Thu, Aug 10, 2017 at 3:26 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> Please give your opinion on OFBIZ-9568 before I continue on OFBIZ-9185
>
> Thanks
>
> Jacques
>
>