Hi Marcel, On Mon, Aug 22, 2011 at 1:16 PM, Marcel Offermans <[email protected]> wrote: > Hello Bram, > > On 16 Aug 2011, at 11:35 , Bram de Kruijff wrote: > >> On Wed, Aug 3, 2011 at 5:01 PM, Marcel Offermans >> <[email protected]> wrote: >>> On 3 Aug 2011, at 16:20 , Bram de Kruijff wrote: >>> >>>> working with the new REST api doing some random CRUD on objects and >>>> noticed I can not delete targets? As the webui does not support >>>> deleting of target either I am kind of wondering how this works (or >>>> should work) conceptually. Are there attributes I can set to make them >>>> deletable? >>> >>> At the moment you cannot delete targets. >> >> Ok >> >>> Once a target exists, it accumulates historic data (audit log, versions >>> that are deployed to it). ACE keeps a full history of everything that ever >>> happened, so you cannot currently delete a target. >>> >>> Now obviously we can discuss this, as there might be use cases where you >>> simply do not care about a target (and its history?) anymore, but as the >>> current REST API reflects the client API, delete does not work. >> >> IMHO there are relevant use cases where "you simply do not care about >> a target (and its history)" anymore. My current use cases is in >> development/test being able to setup/teardown (part of or even an >> entire) model. At least in test this should prevent me with a >> clean/deterministic fixture so I dislike random ids. > > With random ids you mean the ones I use in the curl test scripting, as those > were just quickly added to get something working and I agree they're not the > best way forward for doing testing. > >> Also in a real >> live deployment I think when targets are simply gone (eg. sysop typo >> during deployment of a target) they should not clutter the model >> unnecessarily and thus be deletable. > > For sysop typos I agree, you should be able to remove those again. For > scenarios where a target was there in the past, but is no longer, you can > argue if you want to just hide it now (and keep its history for completeness > sake) or delete it and everything associated with it. > > That being said, I would not mind implementing a "delete" feature and letting > the user decide what he wants.
+1 IMHO this with authorization (another topic), leaving are you really sure dialogs up to clients, should do. grz Bram > Greetings, Marcel > >
