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 <nicolas.ma...@nereide.fr> 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 >> >> >> >
