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
