ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram de Kruijff <>
Subject Re: CRUD on targets howto (via REST)
Date Mon, 22 Aug 2011 12:56:20 GMT
Hi Marcel,

On Mon, Aug 22, 2011 at 1:16 PM, Marcel Offermans
<> 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
>> <> 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
>> 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
> 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.


> Greetings, Marcel

View raw message