Does the deleteWorkEffort really always works?

[Jacques Le Roux]

Hi,

I looked closely and I do not understand how the deleteWorkEffort service can work. Especially when a Workeffort has an established relationship with
a RuntimeData. If someone has some clues I'm interested!

Also CustRequestWorkEffort is missing in deleteWorkEffort, please confirm if you can.

Besides (minor) ApplicationSandbox is maybe missing in the implementation of deleteWorkEffort.
There is indeed a workeffortId in ApplicationSandbox.
So ApplicationSandbox is indirectly linked to Workeffort by RuntimeData.
But it can anyway be deleted by a simple delete-by-and (or alike), so not a problem for deleteWorkEffort, though this case could be handled there also.

Jacques

[Jacques Le Roux]

I created https://issues.apache.org/jira/browse/OFBIZ-9185 please comment

Thanks

Jacques


Le 19/01/2017 à 21:35, Jacques Le Roux a écrit :

> Hi,
>
> I looked closely and I do not understand how the deleteWorkEffort service can work. Especially when a Workeffort has an established relationship
> with a RuntimeData. If someone has some clues I'm interested!
>
> Also CustRequestWorkEffort is missing in deleteWorkEffort, please confirm if you can.
>
> Besides (minor) ApplicationSandbox is maybe missing in the implementation of deleteWorkEffort.
> There is indeed a workeffortId in ApplicationSandbox.
> So ApplicationSandbox is indirectly linked to Workeffort by RuntimeData.
> But it can anyway be deleted by a simple delete-by-and (or alike), so not a problem for deleteWorkEffort, though this case could be handled there also.
>
> Jacques
>
>

[Scott Gray-3]

What comments are you looking for?  It either works or it doesn't.

A couple of things to consider:
- Is there really a good reason to delete a WorkEffort record when changing
its status should be sufficient?
- Maybe it doesn't work now because the data model has changed since it was
introduced?
- Maybe it only ever worked for the contributor's use case which didn't
make use of the foreign keys that concern you?

Regardless there are only two paths of action: fix it or remove it.

My preference is for the latter because I can't think of any *good* reasons
to remove a WorkEffort record.

Regards
Scott

On 23 January 2017 at 01:58, Jacques Le Roux <[hidden email]>
wrote:

> I created https://issues.apache.org/jira/browse/OFBIZ-9185 please comment
>
> Thanks
>
> Jacques
>
>
>
> Le 19/01/2017 à 21:35, Jacques Le Roux a écrit :
>
>> Hi,
>>
>> I looked closely and I do not understand how the deleteWorkEffort service
>> can work. Especially when a Workeffort has an established relationship with
>> a RuntimeData. If someone has some clues I'm interested!
>>
>> Also CustRequestWorkEffort is missing in deleteWorkEffort, please confirm
>> if you can.
>>
>> Besides (minor) ApplicationSandbox is maybe missing in the implementation
>> of deleteWorkEffort.
>> There is indeed a workeffortId in ApplicationSandbox.
>> So ApplicationSandbox is indirectly linked to Workeffort by RuntimeData.
>> But it can anyway be deleted by a simple delete-by-and (or alike), so not
>> a problem for deleteWorkEffort, though this case could be handled there
>> also.
>>
>> Jacques
>>
>>
>>
>

[Paul Foxworthy]

Hi Jacques and Scott,

On 23 January 2017 at 09:08, Scott Gray <[hidden email]>
wrote:


> I can't think of any *good* reasons to remove a WorkEffort record.


Hear, hear. In general, OFBiz expires an entity by setting the thruDate.
What's so special about WorkEffort?

Cheers

Paul

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Nicolas Malin-2]

WorkEffort is a complexe entity as much technical aspect as functional
cover :)

On the Jacques's case, the workEffort is used to follow jobSandox
activity after user command and in logical delete all older workEffort
to minimize the history (like jenkins with his scheduler).

After your remarks, I think call deleteWorkEffort isn't logical without
functional context. If we want delete a WorkEffort, we need to
understand the this context and in this case prepare the deletion by a
dedicate service (remove all potential FK and so one) before call the
standard service.

Nicolas

Le 23/01/2017 à 11:10, Paul Foxworthy a écrit :

> Hi Jacques and Scott,
>
> On 23 January 2017 at 09:08, Scott Gray <[hidden email]>
> wrote:
>
>
>> I can't think of any *good* reasons to remove a WorkEffort record.
>
> Hear, hear. In general, OFBiz expires an entity by setting the thruDate.
> What's so special about WorkEffort?
>
> Cheers
>
> Paul
>

[Jacques Le Roux]

Thanks for your comments, though in OFBIZ-9185 would have been better ;)

I answered there, please do so

Thanks

Jacques

Le 23/01/2017 à 11:55, Nicolas Malin a écrit :

> WorkEffort is a complexe entity as much technical aspect as functional cover :)
>
> On the Jacques's case, the workEffort is used to follow jobSandox activity after user command and in logical delete all older workEffort to minimize
> the history (like jenkins with his scheduler).
>
> After your remarks, I think call deleteWorkEffort isn't logical without functional context. If we want delete a WorkEffort, we need to understand
> the this context and in this case prepare the deletion by a dedicate service (remove all potential FK and so one) before call the standard service.
>
> Nicolas
>
> Le 23/01/2017 à 11:10, Paul Foxworthy a écrit :
>> Hi Jacques and Scott,
>>
>> On 23 January 2017 at 09:08, Scott Gray <[hidden email]>
>> wrote:
>>
>>
>>> I can't think of any *good* reasons to remove a WorkEffort record.
>>
>> Hear, hear. In general, OFBiz expires an entity by setting the thruDate.
>> What's so special about WorkEffort?
>>
>> Cheers
>>
>> Paul
>>
>
>

[Rishi Solanki]

Agree on all points shared by Scott, Paul and Nicolas. Also valid concern
raised in this thread by Jacques. Thanks!

As described by Nicolas, that work_effort is complex entity and we should
consider the functional context for it, if we wnat to delete a work_effort.
Still I think, until business or dba not force we should maintain the
historical data. I mean to say, we have date fileds and status fields in
the work_effort the maintain/filter them. Also on closing/cancelling the
workeffort case by case basis system clear them out from the system.

So we need a delete service for work_effort which requires extra handling
for date fields, status field with some better algorithm so that once
business decided to remove it, system should always remove instead of
sending exception on dependencies.

Thanks!

Kind Regards,
--
Rishi Solanki
Sr. Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Mon, Jan 23, 2017 at 4:25 PM, Nicolas Malin <[hidden email]>
wrote:

> WorkEffort is a complexe entity as much technical aspect as functional
> cover :)
>
> On the Jacques's case, the workEffort is used to follow jobSandox activity
> after user command and in logical delete all older workEffort to minimize
> the history (like jenkins with his scheduler).
>
> After your remarks, I think call deleteWorkEffort isn't logical without
> functional context. If we want delete a WorkEffort, we need to understand
> the this context and in this case prepare the deletion by a dedicate
> service (remove all potential FK and so one) before call the standard
> service.
>
> Nicolas
>
>
> Le 23/01/2017 à 11:10, Paul Foxworthy a écrit :
>
>> Hi Jacques and Scott,
>>
>> On 23 January 2017 at 09:08, Scott Gray <[hidden email]>
>> wrote:
>>
>>
>> I can't think of any *good* reasons to remove a WorkEffort record.
>>>
>>
>> Hear, hear. In general, OFBiz expires an entity by setting the thruDate.
>> What's so special about WorkEffort?
>>
>> Cheers
>>
>> Paul
>>
>>
>

[Jacques Le Roux]

Le 23/01/2017 à 11:10, Paul Foxworthy a écrit :

> Hi Jacques and Scott,
>
> On 23 January 2017 at 09:08, Scott Gray <[hidden email]>
> wrote:
>
>
>> I can't think of any *good* reasons to remove a WorkEffort record.
>
> Hear, hear. In general, OFBiz expires an entity by setting the thruDate.
> What's so special about WorkEffort?
>
> Cheers
>
> Paul
>

Thanks Paul,

I agree but in some cases you want to remove entities temporarily created. In this case it relates with jobs and once finished there are no reasons to
keep the intermediate data.

Jacques

[Jacques Le Roux]

Please answer in the Jira :)

I made a more generic proposition about remove-related there

Jacques


Le 23/01/2017 à 14:31, Rishi Solanki a écrit :

> Agree on all points shared by Scott, Paul and Nicolas. Also valid concern
> raised in this thread by Jacques. Thanks!
>
> As described by Nicolas, that work_effort is complex entity and we should
> consider the functional context for it, if we wnat to delete a work_effort.
> Still I think, until business or dba not force we should maintain the
> historical data. I mean to say, we have date fileds and status fields in
> the work_effort the maintain/filter them. Also on closing/cancelling the
> workeffort case by case basis system clear them out from the system.
>
> So we need a delete service for work_effort which requires extra handling
> for date fields, status field with some better algorithm so that once
> business decided to remove it, system should always remove instead of
> sending exception on dependencies.
>
> Thanks!
>
> Kind Regards,
> --
> Rishi Solanki
> Sr. Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>
> On Mon, Jan 23, 2017 at 4:25 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>> WorkEffort is a complexe entity as much technical aspect as functional
>> cover :)
>>
>> On the Jacques's case, the workEffort is used to follow jobSandox activity
>> after user command and in logical delete all older workEffort to minimize
>> the history (like jenkins with his scheduler).
>>
>> After your remarks, I think call deleteWorkEffort isn't logical without
>> functional context. If we want delete a WorkEffort, we need to understand
>> the this context and in this case prepare the deletion by a dedicate
>> service (remove all potential FK and so one) before call the standard
>> service.
>>
>> Nicolas
>>
>>
>> Le 23/01/2017 à 11:10, Paul Foxworthy a écrit :
>>
>>> Hi Jacques and Scott,
>>>
>>> On 23 January 2017 at 09:08, Scott Gray <[hidden email]>
>>> wrote:
>>>
>>>
>>> I can't think of any *good* reasons to remove a WorkEffort record.
>>> Hear, hear. In general, OFBiz expires an entity by setting the thruDate.
>>> What's so special about WorkEffort?
>>>
>>> Cheers
>>>
>>> Paul
>>>
>>>

[Jacques Le Roux]

Thanks Nicolas,

Fortunately in my case I could get rid of the FK and deleteWorkeffort then worked like a charm. But I thnought about that this weelend and I see more
the problem lying in the remove-related Minilang feature, see my comment in the Jira

Jacques

Le 23/01/2017 à 11:55, Nicolas Malin a écrit :

> WorkEffort is a complexe entity as much technical aspect as functional cover :)
>
> On the Jacques's case, the workEffort is used to follow jobSandox activity after user command and in logical delete all older workEffort to minimize
> the history (like jenkins with his scheduler).
>
> After your remarks, I think call deleteWorkEffort isn't logical without functional context. If we want delete a WorkEffort, we need to understand
> the this context and in this case prepare the deletion by a dedicate service (remove all potential FK and so one) before call the standard service.
>
> Nicolas
>
> Le 23/01/2017 à 11:10, Paul Foxworthy a écrit :
>> Hi Jacques and Scott,
>>
>> On 23 January 2017 at 09:08, Scott Gray <[hidden email]>
>> wrote:
>>
>>
>>> I can't think of any *good* reasons to remove a WorkEffort record.
>>
>> Hear, hear. In general, OFBiz expires an entity by setting the thruDate.
>> What's so special about WorkEffort?
>>
>> Cheers
>>
>> Paul
>>
>
>