Remove as much as possible delete and remove services

[Jacques Le Roux]

Hi,

After a 1st discussion with Deepak at OFBIZ-9185, we had another at OFBIZ-9543.

We claim that we should not remove entities records because of auditing. But we have at 157 services with names starting with "remove" and 538
starting with "delete"

I suggest that we remove as much as possible of these services and have only expire services for those which support expire (ie have from and thru dates).

For instance I was curious about deleteParty, but what it currently does is only returning the "partyservices.cannot_delete_party_not_implemented"
label. This is pre Apache era (ie there for 10+ years)!

In OFBIZ-9543 Deepak rightly suggested that we keep delete services for Assoc kind of entities. But definitely remove delete service for entity like
Party, WorkEffort, Product, etc those have n number of foreign key constraints...

What do you think, other ideas?

Jacques

[Paul Foxworthy]

Hi all,

Some services already expire rather than delete, so it's not as bad as
Jacques suggests.

One example is deletePaymentMethod (
https://github.com/apache/ofbiz-framework/blob/5fa047abd5c0f96d81cd3f9c9547564abe7fe369/applications/accounting/src/main/java/org/apache/ofbiz/accounting/payment/PaymentMethodServices.java#L98
).

I would be in favour of changing the names of these services to say
"expire" instead of "delete", but that's a big change and we would need to
think carefully about what might be disrupted by that.

Cheers

Paul

On 2 August 2017 at 00:34, Jacques Le Roux <[hidden email]>
wrote:

> Hi,
>
> After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> OFBIZ-9543.
>
> We claim that we should not remove entities records because of auditing.
> But we have at 157 services with names starting with "remove" and 538
> starting with "delete"
>
> I suggest that we remove as much as possible of these services and have
> only expire services for those which support expire (ie have from and thru
> dates).
>
> For instance I was curious about deleteParty, but what it currently does
> is only returning the "partyservices.cannot_delete_party_not_implemented"
> label. This is pre Apache era (ie there for 10+ years)!
>
> In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
> Assoc kind of entities. But definitely remove delete service for entity
> like Party, WorkEffort, Product, etc those have n number of foreign key
> constraints...
>
> What do you think, other ideas?
>
> Jacques
>
>

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

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

[Arun Patidar-2]

Hi Jacques,

+1 for idea of removing/renaming 'delete and remove' services and use
'expire' service instead.

One more point to consider here that, most of the  'expire' services calls
'update' service internally. So, can we say that there is no need of expire
services? We can manage expire action only through controller request name.
WDYT?



--
Thanks & Regards
---
Arun Patidar
Manager, Enterprise Software Development

HotWax Systems Pvt Ltd.

www.hotwaxsystems.com


On Wed, Aug 2, 2017 at 5:52 AM, Paul Foxworthy <[hidden email]> wrote:

> Hi all,
>
> Some services already expire rather than delete, so it's not as bad as
> Jacques suggests.
>
> One example is deletePaymentMethod (
> https://github.com/apache/ofbiz-framework/blob/
> 5fa047abd5c0f96d81cd3f9c9547564abe7fe369/applications/
> accounting/src/main/java/org/apache/ofbiz/accounting/
> payment/PaymentMethodServices.java#L98
> ).
>
> I would be in favour of changing the names of these services to say
> "expire" instead of "delete", but that's a big change and we would need to
> think carefully about what might be disrupted by that.
>
> Cheers
>
> Paul
>
> On 2 August 2017 at 00:34, Jacques Le Roux <[hidden email]>
> wrote:
>
> > Hi,
> >
> > After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> > OFBIZ-9543.
> >
> > We claim that we should not remove entities records because of auditing.
> > But we have at 157 services with names starting with "remove" and 538
> > starting with "delete"
> >
> > I suggest that we remove as much as possible of these services and have
> > only expire services for those which support expire (ie have from and
> thru
> > dates).
> >
> > For instance I was curious about deleteParty, but what it currently does
> > is only returning the "partyservices.cannot_delete_
> party_not_implemented"
> > label. This is pre Apache era (ie there for 10+ years)!
> >
> > In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
> > Assoc kind of entities. But definitely remove delete service for entity
> > like Party, WorkEffort, Product, etc those have n number of foreign key
> > constraints...
> >
> > What do you think, other ideas?
> >
> > Jacques
> >
> >
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

[Deepak Dixit-3]

Hi Arun,

In case of calling update service we have to pass thruDate as mandatory
parameter, We have expire as entityAuto service that care of setting up the
thruDate if not passed. So instead of doing it controller level its good
idea to have expire service.




Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Wed, Aug 2, 2017 at 11:11 AM, Arun Patidar <
[hidden email]> wrote:

> Hi Jacques,
>
> +1 for idea of removing/renaming 'delete and remove' services and use
> 'expire' service instead.
>
> One more point to consider here that, most of the  'expire' services calls
> 'update' service internally. So, can we say that there is no need of expire
> services? We can manage expire action only through controller request name.
> WDYT?
>
>
>
> --
> Thanks & Regards
> ---
> Arun Patidar
> Manager, Enterprise Software Development
>
> HotWax Systems Pvt Ltd.
>
> www.hotwaxsystems.com
>
>
> On Wed, Aug 2, 2017 at 5:52 AM, Paul Foxworthy <[hidden email]>
> wrote:
>
> > Hi all,
> >
> > Some services already expire rather than delete, so it's not as bad as
> > Jacques suggests.
> >
> > One example is deletePaymentMethod (
> > https://github.com/apache/ofbiz-framework/blob/
> > 5fa047abd5c0f96d81cd3f9c9547564abe7fe369/applications/
> > accounting/src/main/java/org/apache/ofbiz/accounting/
> > payment/PaymentMethodServices.java#L98
> > ).
> >
> > I would be in favour of changing the names of these services to say
> > "expire" instead of "delete", but that's a big change and we would need
> to
> > think carefully about what might be disrupted by that.
> >
> > Cheers
> >
> > Paul
> >
> > On 2 August 2017 at 00:34, Jacques Le Roux <[hidden email]
> >
> > wrote:
> >
> > > Hi,
> > >
> > > After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> > > OFBIZ-9543.
> > >
> > > We claim that we should not remove entities records because of
> auditing.
> > > But we have at 157 services with names starting with "remove" and 538
> > > starting with "delete"
> > >
> > > I suggest that we remove as much as possible of these services and have
> > > only expire services for those which support expire (ie have from and
> > thru
> > > dates).
> > >
> > > For instance I was curious about deleteParty, but what it currently
> does
> > > is only returning the "partyservices.cannot_delete_
> > party_not_implemented"
> > > label. This is pre Apache era (ie there for 10+ years)!
> > >
> > > In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
> > > Assoc kind of entities. But definitely remove delete service for entity
> > > like Party, WorkEffort, Product, etc those have n number of foreign key
> > > constraints...
> > >
> > > What do you think, other ideas?
> > >
> > > Jacques
> > >
> > >
> >
> >
> > --
> > Coherent Software Australia Pty Ltd
> > PO Box 2773
> > Cheltenham Vic 3192
> > Australia
> >
> > Phone: [phone]
> > Web: http://www.coherentsoftware.com.au/
> > Email: [hidden email]
> >
>

[Deepak Dixit-3]

Hi Paul,

The main idea is to avoid confusion, some delete/remove services use expire
pattern and some is used  to delete record. So its not consistent.

We can convert all the remove service (where possible) to expire as you
suggest.

Also we can add fromDate and thruDate where necessary at entity level like
Suraj initiated thread
Proper record maintenance in marketing component
<https://lists.apache.org/thread.html/b80e835df82044394f5076e98fd3463d7b086d6d611618943536c9bd@%3Cdev.ofbiz.apache.org%3E>
Another ticket related to this
https://issues.apache.org/jira/browse/OFBIZ-5959



Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Wed, Aug 2, 2017 at 5:52 AM, Paul Foxworthy <[hidden email]> wrote:

> Hi all,
>
> Some services already expire rather than delete, so it's not as bad as
> Jacques suggests.
>
> One example is deletePaymentMethod (
> https://github.com/apache/ofbiz-framework/blob/5fa047abd5c0f
> 96d81cd3f9c9547564abe7fe369/applications/accounting/src/
> main/java/org/apache/ofbiz/accounting/payment/
> PaymentMethodServices.java#L98
> ).
>
> I would be in favour of changing the names of these services to say
> "expire" instead of "delete", but that's a big change and we would need to
> think carefully about what might be disrupted by that.
>
> Cheers
>
> Paul
>
> On 2 August 2017 at 00:34, Jacques Le Roux <[hidden email]>
> wrote:
>
> > Hi,
> >
> > After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> > OFBIZ-9543.
> >
> > We claim that we should not remove entities records because of auditing.
> > But we have at 157 services with names starting with "remove" and 538
> > starting with "delete"
> >
> > I suggest that we remove as much as possible of these services and have
> > only expire services for those which support expire (ie have from and
> thru
> > dates).
> >
> > For instance I was curious about deleteParty, but what it currently does
> > is only returning the "partyservices.cannot_delete_p
> arty_not_implemented"
> > label. This is pre Apache era (ie there for 10+ years)!
> >
> > In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
> > Assoc kind of entities. But definitely remove delete service for entity
> > like Party, WorkEffort, Product, etc those have n number of foreign key
> > constraints...
> >
> > What do you think, other ideas?
> >
> > Jacques
> >
> >
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

[Arun Patidar-2]

Hello Deepak,

Yes, If we use entity-auto then all looks good and makes sense to me.

--
Thanks & Regards
---
Arun Patidar
Manager, Enterprise Software Development


HotWax Systems Pvt Ltd.www.hotwaxsystems.com


On Wed, Aug 2, 2017 at 11:19 AM, Deepak Dixit <
[hidden email]> wrote:

> Hi Arun,
>
> In case of calling update service we have to pass thruDate as mandatory
> parameter, We have expire as entityAuto service that care of setting up the
> thruDate if not passed. So instead of doing it controller level its good
> idea to have expire service.
>
>
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Wed, Aug 2, 2017 at 11:11 AM, Arun Patidar <
> [hidden email]> wrote:
>
> > Hi Jacques,
> >
> > +1 for idea of removing/renaming 'delete and remove' services and use
> > 'expire' service instead.
> >
> > One more point to consider here that, most of the  'expire' services
> calls
> > 'update' service internally. So, can we say that there is no need of
> expire
> > services? We can manage expire action only through controller request
> name.
> > WDYT?
> >
> >
> >
> > --
> > Thanks & Regards
> > ---
> > Arun Patidar
> > Manager, Enterprise Software Development
> >
> > HotWax Systems Pvt Ltd.
> >
> > www.hotwaxsystems.com
> >
> >
> > On Wed, Aug 2, 2017 at 5:52 AM, Paul Foxworthy <[hidden email]>
> > wrote:
> >
> > > Hi all,
> > >
> > > Some services already expire rather than delete, so it's not as bad as
> > > Jacques suggests.
> > >
> > > One example is deletePaymentMethod (
> > > https://github.com/apache/ofbiz-framework/blob/
> > > 5fa047abd5c0f96d81cd3f9c9547564abe7fe369/applications/
> > > accounting/src/main/java/org/apache/ofbiz/accounting/
> > > payment/PaymentMethodServices.java#L98
> > > ).
> > >
> > > I would be in favour of changing the names of these services to say
> > > "expire" instead of "delete", but that's a big change and we would need
> > to
> > > think carefully about what might be disrupted by that.
> > >
> > > Cheers
> > >
> > > Paul
> > >
> > > On 2 August 2017 at 00:34, Jacques Le Roux <
> [hidden email]
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> > > > OFBIZ-9543.
> > > >
> > > > We claim that we should not remove entities records because of
> > auditing.
> > > > But we have at 157 services with names starting with "remove" and 538
> > > > starting with "delete"
> > > >
> > > > I suggest that we remove as much as possible of these services and
> have
> > > > only expire services for those which support expire (ie have from and
> > > thru
> > > > dates).
> > > >
> > > > For instance I was curious about deleteParty, but what it currently
> > does
> > > > is only returning the "partyservices.cannot_delete_
> > > party_not_implemented"
> > > > label. This is pre Apache era (ie there for 10+ years)!
> > > >
> > > > In OFBIZ-9543 Deepak rightly suggested that we keep delete services
> for
> > > > Assoc kind of entities. But definitely remove delete service for
> entity
> > > > like Party, WorkEffort, Product, etc those have n number of foreign
> key
> > > > constraints...
> > > >
> > > > What do you think, other ideas?
> > > >
> > > > Jacques
> > > >
> > > >
> > >
> > >
> > > --
> > > Coherent Software Australia Pty Ltd
> > > PO Box 2773
> > > Cheltenham Vic 3192
> > > Australia
> > >
> > > Phone: [phone]
> > > Web: http://www.coherentsoftware.com.au/
> > > Email: [hidden email]
> > >
> >
>

[Paul Foxworthy]

On 2 August 2017 at 15:49, Deepak Dixit <[hidden email]>
wrote:

> In case of calling update service we have to pass thruDate as mandatory
> parameter, We have expire as entityAuto service that care of setting up the
> thruDate if not passed. So instead of doing it controller level its good
> idea to have expire service.
>

Thanks Deepak, I agree., the expire services will only need a primary key
and an optional thru date and will do the rest internally. Update services
can be more complicated.

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]

[Swapnil Mane]

+1 for using 'expire' service for all the possible places.

IMO, In ERP systems, we should not delete any information/data. Because
data is the real asset for the any organization. Helping in taking the
business decision.

Thanks, Jacques and Deepak for sharing this.


- Best Regards,
Swapnil M Mane
www.hotwaxsystems.com
www.hotwax.co

On Tue, Aug 1, 2017 at 8:04 PM, Jacques Le Roux <
[hidden email]> wrote:

> Hi,
>
> After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> OFBIZ-9543.
>
> We claim that we should not remove entities records because of auditing.
> But we have at 157 services with names starting with "remove" and 538
> starting with "delete"
>
> I suggest that we remove as much as possible of these services and have
> only expire services for those which support expire (ie have from and thru
> dates).
>
> For instance I was curious about deleteParty, but what it currently does
> is only returning the "partyservices.cannot_delete_party_not_implemented"
> label. This is pre Apache era (ie there for 10+ years)!
>
> In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
> Assoc kind of entities. But definitely remove delete service for entity
> like Party, WorkEffort, Product, etc those have n number of foreign key
> constraints...
>
> What do you think, other ideas?
>
> Jacques
>
>

[Rishi Solanki]

+1 for the proposal with some caution (as suggested by Paul) on picking an
entity as candidate which won't have the delete service with it.

Some basic steps I could think of we should follow in the effort. Please
feel free to add more check points.

1) Identify such entities, where we have to remove the delete/remove
services.
1.1) To make an entity as candidate to fall under this, it should maintain
the status or manage from date and thru date. Like Party and WorkEffort
will have enable/disable flag and statuses. So we can consider them to
follow the pattern mentioned in this thread. May be other entities which
won't have these attributes could fall, but I think it is easiest way to
count any entity IN.
2) Check all occurrences and check what could be the side effect in the
process/workflow and how we can handle them.
3) Once we remove/change all occurrences, remove/change the delete/remove
service for the entity.


Just FYI all, Related discussion started by Suraj in other thread as
"Proper record maintenance in marketing component" which tells we should
add from date and thru date in some entities. So if community agree on that
point then we could consider those entities as well for improvement.




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

On Wed, Aug 2, 2017 at 11:33 AM, Swapnil Mane <
[hidden email]> wrote:

> +1 for using 'expire' service for all the possible places.
>
> IMO, In ERP systems, we should not delete any information/data. Because
> data is the real asset for the any organization. Helping in taking the
> business decision.
>
> Thanks, Jacques and Deepak for sharing this.
>
>
> - Best Regards,
> Swapnil M Mane
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Tue, Aug 1, 2017 at 8:04 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi,
> >
> > After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> > OFBIZ-9543.
> >
> > We claim that we should not remove entities records because of auditing.
> > But we have at 157 services with names starting with "remove" and 538
> > starting with "delete"
> >
> > I suggest that we remove as much as possible of these services and have
> > only expire services for those which support expire (ie have from and
> thru
> > dates).
> >
> > For instance I was curious about deleteParty, but what it currently does
> > is only returning the "partyservices.cannot_delete_
> party_not_implemented"
> > label. This is pre Apache era (ie there for 10+ years)!
> >
> > In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
> > Assoc kind of entities. But definitely remove delete service for entity
> > like Party, WorkEffort, Product, etc those have n number of foreign key
> > constraints...
> >
> > What do you think, other ideas?
> >
> > Jacques
> >
> >
>

[taher]

I agree with the suggested naming convention and proposed work.
Naturally it should be done carefully and slowly.

With that being said, since this discussion is getting traction, I
would suggest that If you are willing to make the effort towards
naming all these services then you might as well consider unifying
them. I was going to start a thread later on suggesting to unify all
services in a new component (similar to datamodel) that maybe we can
call service-library with a similar structure to datamodel.

The reason why I interject in this thread specifically is because it
seems the effort is extensive enough that we might as well make it
bigger to unify and isolate services from the components consuming
them. So you rename + move in one shot.

I don't know if this makes sense to you or you find value in it. So I
thought I'd throw it in the pot and see everyone's inclinations.

On Wed, Aug 2, 2017 at 9:33 AM, Rishi Solanki <[hidden email]> wrote:

> +1 for the proposal with some caution (as suggested by Paul) on picking an
> entity as candidate which won't have the delete service with it.
>
> Some basic steps I could think of we should follow in the effort. Please
> feel free to add more check points.
>
> 1) Identify such entities, where we have to remove the delete/remove
> services.
> 1.1) To make an entity as candidate to fall under this, it should maintain
> the status or manage from date and thru date. Like Party and WorkEffort
> will have enable/disable flag and statuses. So we can consider them to
> follow the pattern mentioned in this thread. May be other entities which
> won't have these attributes could fall, but I think it is easiest way to
> count any entity IN.
> 2) Check all occurrences and check what could be the side effect in the
> process/workflow and how we can handle them.
> 3) Once we remove/change all occurrences, remove/change the delete/remove
> service for the entity.
>
>
> Just FYI all, Related discussion started by Suraj in other thread as
> "Proper record maintenance in marketing component" which tells we should
> add from date and thru date in some entities. So if community agree on that
> point then we could consider those entities as well for improvement.
>
>
>
>
> --
> Rishi Solanki
> Sr Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
> www.hotwax.co
>
> On Wed, Aug 2, 2017 at 11:33 AM, Swapnil Mane <
> [hidden email]> wrote:
>
>> +1 for using 'expire' service for all the possible places.
>>
>> IMO, In ERP systems, we should not delete any information/data. Because
>> data is the real asset for the any organization. Helping in taking the
>> business decision.
>>
>> Thanks, Jacques and Deepak for sharing this.
>>
>>
>> - Best Regards,
>> Swapnil M Mane
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Tue, Aug 1, 2017 at 8:04 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> > Hi,
>> >
>> > After a 1st discussion with Deepak at OFBIZ-9185, we had another at
>> > OFBIZ-9543.
>> >
>> > We claim that we should not remove entities records because of auditing.
>> > But we have at 157 services with names starting with "remove" and 538
>> > starting with "delete"
>> >
>> > I suggest that we remove as much as possible of these services and have
>> > only expire services for those which support expire (ie have from and
>> thru
>> > dates).
>> >
>> > For instance I was curious about deleteParty, but what it currently does
>> > is only returning the "partyservices.cannot_delete_
>> party_not_implemented"
>> > label. This is pre Apache era (ie there for 10+ years)!
>> >
>> > In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
>> > Assoc kind of entities. But definitely remove delete service for entity
>> > like Party, WorkEffort, Product, etc those have n number of foreign key
>> > constraints...
>> >
>> > What do you think, other ideas?
>> >
>> > Jacques
>> >
>> >
>>

[Pierre Smits]

Before a conversion from delete/remove services to expire services takes
place, the associated entities need to be checked to correct those that
don't have from and thru fields.

Best regards,



Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OEM - the unendorsed OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Aug 2, 2017 at 8:37 AM, Taher Alkhateeb <[hidden email]>
wrote:

> I agree with the suggested naming convention and proposed work.
> Naturally it should be done carefully and slowly.
>
> With that being said, since this discussion is getting traction, I
> would suggest that If you are willing to make the effort towards
> naming all these services then you might as well consider unifying
> them. I was going to start a thread later on suggesting to unify all
> services in a new component (similar to datamodel) that maybe we can
> call service-library with a similar structure to datamodel.
>
> The reason why I interject in this thread specifically is because it
> seems the effort is extensive enough that we might as well make it
> bigger to unify and isolate services from the components consuming
> them. So you rename + move in one shot.
>
> I don't know if this makes sense to you or you find value in it. So I
> thought I'd throw it in the pot and see everyone's inclinations.
>
> On Wed, Aug 2, 2017 at 9:33 AM, Rishi Solanki <[hidden email]>
> wrote:
> > +1 for the proposal with some caution (as suggested by Paul) on picking
> an
> > entity as candidate which won't have the delete service with it.
> >
> > Some basic steps I could think of we should follow in the effort. Please
> > feel free to add more check points.
> >
> > 1) Identify such entities, where we have to remove the delete/remove
> > services.
> > 1.1) To make an entity as candidate to fall under this, it should
> maintain
> > the status or manage from date and thru date. Like Party and WorkEffort
> > will have enable/disable flag and statuses. So we can consider them to
> > follow the pattern mentioned in this thread. May be other entities which
> > won't have these attributes could fall, but I think it is easiest way to
> > count any entity IN.
> > 2) Check all occurrences and check what could be the side effect in the
> > process/workflow and how we can handle them.
> > 3) Once we remove/change all occurrences, remove/change the delete/remove
> > service for the entity.
> >
> >
> > Just FYI all, Related discussion started by Suraj in other thread as
> > "Proper record maintenance in marketing component" which tells we should
> > add from date and thru date in some entities. So if community agree on
> that
> > point then we could consider those entities as well for improvement.
> >
> >
> >
> >
> > --
> > Rishi Solanki
> > Sr Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: [phone]
> > http://www.hotwaxsystems.com
> > www.hotwax.co
> >
> > On Wed, Aug 2, 2017 at 11:33 AM, Swapnil Mane <
> > [hidden email]> wrote:
> >
> >> +1 for using 'expire' service for all the possible places.
> >>
> >> IMO, In ERP systems, we should not delete any information/data. Because
> >> data is the real asset for the any organization. Helping in taking the
> >> business decision.
> >>
> >> Thanks, Jacques and Deepak for sharing this.
> >>
> >>
> >> - Best Regards,
> >> Swapnil M Mane
> >> www.hotwaxsystems.com
> >> www.hotwax.co
> >>
> >> On Tue, Aug 1, 2017 at 8:04 PM, Jacques Le Roux <
> >> [hidden email]> wrote:
> >>
> >> > Hi,
> >> >
> >> > After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> >> > OFBIZ-9543.
> >> >
> >> > We claim that we should not remove entities records because of
> auditing.
> >> > But we have at 157 services with names starting with "remove" and 538
> >> > starting with "delete"
> >> >
> >> > I suggest that we remove as much as possible of these services and
> have
> >> > only expire services for those which support expire (ie have from and
> >> thru
> >> > dates).
> >> >
> >> > For instance I was curious about deleteParty, but what it currently
> does
> >> > is only returning the "partyservices.cannot_delete_
> >> party_not_implemented"
> >> > label. This is pre Apache era (ie there for 10+ years)!
> >> >
> >> > In OFBIZ-9543 Deepak rightly suggested that we keep delete services
> for
> >> > Assoc kind of entities. But definitely remove delete service for
> entity
> >> > like Party, WorkEffort, Product, etc those have n number of foreign
> key
> >> > constraints...
> >> >
> >> > What do you think, other ideas?
> >> >
> >> > Jacques
> >> >
> >> >
> >>
>

[Paul Foxworthy]

On 2 August 2017 at 16:37, Taher Alkhateeb <[hidden email]>
wrote:

> If you are willing to make the effort towards
> naming all these services then you might as well consider unifying
> them.


Hi Taher,

Are you proposing one expire service for all entities, which sets the
thruDate attribute?

If I understand you right, what would we do for entities without a
thruDate? How would we define the expected paramaters, when primary keys
vary between the different entities?

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]

[taher]

Hi Paul, no what I meant is a new single component where move all
services to it. The reason I suggested that is to reduce "mass
operations" and make them into one.

Our services require a lot of cleanup, renaming, fixing, etc ... so I
guess I just rushed an email which I wanted to carefully write in a
more comprehensive thread, but I'm just not sure if people are
interested in going that route

On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy <[hidden email]> wrote:

> On 2 August 2017 at 16:37, Taher Alkhateeb <[hidden email]>
> wrote:
>
>> If you are willing to make the effort towards
>> naming all these services then you might as well consider unifying
>> them.
>
>
> Hi Taher,
>
> Are you proposing one expire service for all entities, which sets the
> thruDate attribute?
>
> If I understand you right, what would we do for entities without a
> thruDate? How would we define the expected paramaters, when primary keys
> vary between the different entities?
>
> 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]

[Deepak Dixit-3]

Hi Taher,

I think we can keep both work independent, as it will be very messy if we
do renaming/cleaning and movement in single shot.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb <[hidden email]>
wrote:

> Hi Paul, no what I meant is a new single component where move all
> services to it. The reason I suggested that is to reduce "mass
> operations" and make them into one.
>
> Our services require a lot of cleanup, renaming, fixing, etc ... so I
> guess I just rushed an email which I wanted to carefully write in a
> more comprehensive thread, but I'm just not sure if people are
> interested in going that route
>
> On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy <[hidden email]>
> wrote:
> > On 2 August 2017 at 16:37, Taher Alkhateeb <[hidden email]>
> > wrote:
> >
> >> If you are willing to make the effort towards
> >> naming all these services then you might as well consider unifying
> >> them.
> >
> >
> > Hi Taher,
> >
> > Are you proposing one expire service for all entities, which sets the
> > thruDate attribute?
> >
> > If I understand you right, what would we do for entities without a
> > thruDate? How would we define the expected paramaters, when primary keys
> > vary between the different entities?
> >
> > 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]
>

[Jacques Le Roux]

+1

Jacques


Le 02/08/2017 à 10:44, Deepak Dixit a écrit :

> Hi Taher,
>
> I think we can keep both work independent, as it will be very messy if we
> do renaming/cleaning and movement in single shot.
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb <[hidden email]>
> wrote:
>
>> Hi Paul, no what I meant is a new single component where move all
>> services to it. The reason I suggested that is to reduce "mass
>> operations" and make them into one.
>>
>> Our services require a lot of cleanup, renaming, fixing, etc ... so I
>> guess I just rushed an email which I wanted to carefully write in a
>> more comprehensive thread, but I'm just not sure if people are
>> interested in going that route
>>
>> On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy <[hidden email]>
>> wrote:
>>> On 2 August 2017 at 16:37, Taher Alkhateeb <[hidden email]>
>>> wrote:
>>>
>>>> If you are willing to make the effort towards
>>>> naming all these services then you might as well consider unifying
>>>> them.
>>>
>>> Hi Taher,
>>>
>>> Are you proposing one expire service for all entities, which sets the
>>> thruDate attribute?
>>>
>>> If I understand you right, what would we do for entities without a
>>> thruDate? How would we define the expected paramaters, when primary keys
>>> vary between the different entities?
>>>
>>> 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]

[Rishi Solanki]

Taher, Are you proposing to move only crud services or crud and basic
services or all. Asking this to understand the exact proposal.

+1 Deepak to keep the work independent.


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

On Wed, Aug 2, 2017 at 2:22 PM, Jacques Le Roux <
[hidden email]> wrote:

> +1
>
> Jacques
>
>
>
> Le 02/08/2017 à 10:44, Deepak Dixit a écrit :
>
>> Hi Taher,
>>
>> I think we can keep both work independent, as it will be very messy if we
>> do renaming/cleaning and movement in single shot.
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb <
>> [hidden email]>
>> wrote:
>>
>> Hi Paul, no what I meant is a new single component where move all
>>> services to it. The reason I suggested that is to reduce "mass
>>> operations" and make them into one.
>>>
>>> Our services require a lot of cleanup, renaming, fixing, etc ... so I
>>> guess I just rushed an email which I wanted to carefully write in a
>>> more comprehensive thread, but I'm just not sure if people are
>>> interested in going that route
>>>
>>> On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy <[hidden email]>
>>> wrote:
>>>
>>>> On 2 August 2017 at 16:37, Taher Alkhateeb <[hidden email]>
>>>> wrote:
>>>>
>>>> If you are willing to make the effort towards
>>>>> naming all these services then you might as well consider unifying
>>>>> them.
>>>>>
>>>>
>>>> Hi Taher,
>>>>
>>>> Are you proposing one expire service for all entities, which sets the
>>>> thruDate attribute?
>>>>
>>>> If I understand you right, what would we do for entities without a
>>>> thruDate? How would we define the expected paramaters, when primary keys
>>>> vary between the different entities?
>>>>
>>>> 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]
>>>>
>>>
>

[taher]

Hi Rishi , all

I guess Deepak makes sense so let's defer what I said for now and focus on
the renaming effort. I'll start another thread at a future point in time

On Aug 2, 2017 12:29 PM, "Rishi Solanki" <[hidden email]> wrote:

> Taher, Are you proposing to move only crud services or crud and basic
> services or all. Asking this to understand the exact proposal.
>
> +1 Deepak to keep the work independent.
>
>
> --
> Rishi Solanki
> Sr Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
> www.hotwax.co
>
> On Wed, Aug 2, 2017 at 2:22 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > +1
> >
> > Jacques
> >
> >
> >
> > Le 02/08/2017 à 10:44, Deepak Dixit a écrit :
> >
> >> Hi Taher,
> >>
> >> I think we can keep both work independent, as it will be very messy if
> we
> >> do renaming/cleaning and movement in single shot.
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Dixit
> >> www.hotwaxsystems.com
> >> www.hotwax.co
> >>
> >> On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb <
> >> [hidden email]>
> >> wrote:
> >>
> >> Hi Paul, no what I meant is a new single component where move all
> >>> services to it. The reason I suggested that is to reduce "mass
> >>> operations" and make them into one.
> >>>
> >>> Our services require a lot of cleanup, renaming, fixing, etc ... so I
> >>> guess I just rushed an email which I wanted to carefully write in a
> >>> more comprehensive thread, but I'm just not sure if people are
> >>> interested in going that route
> >>>
> >>> On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy <[hidden email]>
> >>> wrote:
> >>>
> >>>> On 2 August 2017 at 16:37, Taher Alkhateeb <
> [hidden email]>
> >>>> wrote:
> >>>>
> >>>> If you are willing to make the effort towards
> >>>>> naming all these services then you might as well consider unifying
> >>>>> them.
> >>>>>
> >>>>
> >>>> Hi Taher,
> >>>>
> >>>> Are you proposing one expire service for all entities, which sets the
> >>>> thruDate attribute?
> >>>>
> >>>> If I understand you right, what would we do for entities without a
> >>>> thruDate? How would we define the expected paramaters, when primary
> keys
> >>>> vary between the different entities?
> >>>>
> >>>> 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]

Hello,

I'm in favor to have a generic crud soa api as possible coherent with
the following model :

* createEntity -> create the new entity
* updateEntity -> update all field
* deleteEntity -> remove entity
* expireEntity -> functionnal remove by thruDate expiration (or other
field related)

But I'm not in favor to remove "delete service" by default but more
replace it on OFBiz applications by expire. If all is clear we can keep
delete and expire and when you create you own specificcod it's your
responsability to call expire or delete. I prefer that developer call
deleteEntity instead of call GV.remove() directly, but between delete
and expire, a developer will thinks what call would be needed in his case.

Nicolas

Le 01/08/2017 à 16:34, Jacques Le Roux a écrit :

> Hi,
>
> After a 1st discussion with Deepak at OFBIZ-9185, we had another at
> OFBIZ-9543.
>
> We claim that we should not remove entities records because of
> auditing. But we have at 157 services with names starting with
> "remove" and 538 starting with "delete"
>
> I suggest that we remove as much as possible of these services and
> have only expire services for those which support expire (ie have from
> and thru dates).
>
> For instance I was curious about deleteParty, but what it currently
> does is only returning the
> "partyservices.cannot_delete_party_not_implemented" label. This is pre
> Apache era (ie there for 10+ years)!
>
> In OFBIZ-9543 Deepak rightly suggested that we keep delete services
> for Assoc kind of entities. But definitely remove delete service for
> entity like Party, WorkEffort, Product, etc those have n number of
> foreign key constraints...
>
> What do you think, other ideas?
>
> Jacques
>
>

[Deepak Dixit-3]

Hi Nicolas,

We can keep delete/remove service for other entity as well (aprt from
Assoc), but I think there is no use of these kind of delete service due to
foreign key constraints .
I am fine with your proposal as well.


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Thu, Aug 3, 2017 at 10:17 PM, Nicolas Malin <[hidden email]>
wrote:

> Hello,
>
> I'm in favor to have a generic crud soa api as possible coherent with the
> following model :
>
> * createEntity -> create the new entity
> * updateEntity -> update all field
> * deleteEntity -> remove entity
> * expireEntity -> functionnal remove by thruDate expiration (or other
> field related)
>
> But I'm not in favor to remove "delete service" by default but more
> replace it on OFBiz applications by expire. If all is clear we can keep
> delete and expire and when you create you own specificcod it's your
> responsability to call expire or delete. I prefer that developer call
> deleteEntity instead of call GV.remove() directly, but between delete and
> expire, a developer will thinks what call would be needed in his case.
>
> Nicolas
>
>
> Le 01/08/2017 à 16:34, Jacques Le Roux a écrit :
>
>> Hi,
>>
>> After a 1st discussion with Deepak at OFBIZ-9185, we had another at
>> OFBIZ-9543.
>>
>> We claim that we should not remove entities records because of auditing.
>> But we have at 157 services with names starting with "remove" and 538
>> starting with "delete"
>>
>> I suggest that we remove as much as possible of these services and have
>> only expire services for those which support expire (ie have from and thru
>> dates).
>>
>> For instance I was curious about deleteParty, but what it currently does
>> is only returning the "partyservices.cannot_delete_party_not_implemented"
>> label. This is pre Apache era (ie there for 10+ years)!
>>
>> In OFBIZ-9543 Deepak rightly suggested that we keep delete services for
>> Assoc kind of entities. But definitely remove delete service for entity
>> like Party, WorkEffort, Product, etc those have n number of foreign key
>> constraints...
>>
>> What do you think, other ideas?
>>
>> Jacques
>>
>>
>>
>

[Jacques Le Roux]

Hi Nicolas,

Inline...


Le 03/08/2017 à 18:47, Nicolas Malin a écrit :

> Hello,
>
> I'm in favor to have a generic crud soa api as possible coherent with the following model :
>
> * createEntity -> create the new entity
> * updateEntity -> update all field
> * deleteEntity -> remove entity
> * expireEntity -> functionnal remove by thruDate expiration (or other field related)
>
> But I'm not in favor to remove "delete service" by default but more replace it on OFBiz applications by expire.

Yes that's what I meant also.

> If all is clear we can keep delete and expire and when you create you own specificcod it's your responsability to call expire or delete. I prefer
> that developer call deleteEntity instead of call GV.remove() directly, but between delete and expire, a developer will thinks what call would be
> needed in his case.
I mostly agree, but I also believe that there are a number of them that should be removed.
I will begin by remove deleteWorkEffort (OFBIZ-9185), removeUserLoginToSecurityGroup and deleteParty (OFBIZ-9543).
Then I will create a Jira to collect all the ideas we got so far in this thread.

Thanks to All!

Jacques

>
> Nicolas
>
> Le 01/08/2017 à 16:34, Jacques Le Roux a écrit :
>> Hi,
>>
>> After a 1st discussion with Deepak at OFBIZ-9185, we had another at OFBIZ-9543.
>>
>> We claim that we should not remove entities records because of auditing. But we have at 157 services with names starting with "remove" and 538
>> starting with "delete"
>>
>> I suggest that we remove as much as possible of these services and have only expire services for those which support expire (ie have from and thru
>> dates).
>>
>> For instance I was curious about deleteParty, but what it currently does is only returning the "partyservices.cannot_delete_party_not_implemented"
>> label. This is pre Apache era (ie there for 10+ years)!
>>
>> In OFBIZ-9543 Deepak rightly suggested that we keep delete services for Assoc kind of entities. But definitely remove delete service for entity
>> like Party, WorkEffort, Product, etc those have n number of foreign key constraints...
>>
>> What do you think, other ideas?
>>
>> Jacques
>>
>>
>
>