Re: Remove as much as possible delete and remove services

Hi Paul, I will start a new thread later on to keep this one focused like others suggested. I should take my time and really develop the idea and then share it on the ML. Cheers, On Aug 4, 2017 5:17 AM, "Paul Foxworthy" wrote: > On 2 August 2017 at 18:14, Taher Alkhateeb > wrote: > > > what I

Re: Remove as much as possible delete and remove services

On 2 August 2017 at 18:14, Taher Alkhateeb wrote: > 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. > Hi Taher, I'm still not clear what you have in mind. By "mass operation", I think yo

Re: Remove as much as possible delete and remove services

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 -

Re: Remove as much as possible delete and remove services

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 Th

Re: Remove as much as possible delete and remove services

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)

Re: Remove as much as possible delete and remove services

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" wrote: > Taher, Are you proposing to move only crud services or crud and basic > services o

Re: Remove as much as possible delete and remove services

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: +91-9893287847 http://www.hot

Re: Remove as much as possible delete and remove services

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

Re: Remove as much as possible delete and remove services

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 wrote: > Hi Paul, no what I meant is a new

Re: Remove as much as possible delete and remove services

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

Re: Remove as much as possible delete and remove services

On 2 August 2017 at 16:37, Taher Alkhateeb 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 yo

Re: Remove as much as possible delete and remove services

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 OFBiz based solutions & services OEM - the unendorsed

Re: Remove as much as possible delete and remove services

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 con

Re: Remove as much as possible delete and remove services

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

Re: Remove as much as possible delete and remove services

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

Re: Remove as much as possible delete and remove services

On 2 August 2017 at 15:49, Deepak Dixit 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 s

Re: Remove as much as possible delete and remove services

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 < deepak.di...@hotwaxsystems.com> wrote

Re: Remove as much as possible delete and remove services

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

Re: Remove as much as possible delete and remove services

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 ww

Re: Remove as much as possible delete and remove services

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

Re: Remove as much as possible delete and remove services

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

Remove as much as possible delete and remove services

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 possibl