Deletes

[Greg Young]

I found it quite odd that eventsourced needs the underlying implementation to support arbitrary deletes as this breaks many good things. What is the use case they are needed for? Is this something that can be done without deleting of events?

--

Studying for the Turing test

[Martin Krasser]

On 27.05.14 21:49, Greg Young wrote:

I found it quite odd that eventsourced needs the underlying implementation to support arbitrary deletes as this breaks many good things. What is the use case they are needed for?

Compensating invalid (but already journaled) commands when doing command sourcing, and persistent channels (where acks delete messages persisted by a channel).

Is this something that can be done without deleting of events?

You can cheat by only adding deletion markers (tombstones) but never physically delete individual messages. This is only an issue for applications that want to delete messages for saving disk space.

--

Studying for the Turing test

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

[Greg Young]

Sorry for delay in responding been travelling a bunch.

On Wed, May 28, 2014 at 8:18 PM, Martin Krasser <kras...@googlemail.com> wrote:

On 27.05.14 21:49, Greg Young wrote:

I found it quite odd that eventsourced needs the underlying implementation to support arbitrary deletes as this breaks many good things. What is the use case they are needed for?

Compensating invalid (but already journaled) commands when doing command sourcing, and persistent channels (where acks delete messages persisted by a channel).

Maybe it would be better to separate these interfaces so people understand varying requirements on the storage when they are using certain client behaviours. At minimum we would be able to turn off all the tracking of this info (much more performant) when the client isn't using it.

 

Is this something that can be done without deleting of events?

You can cheat by only adding deletion markers (tombstones) but never physically delete individual messages. This is only an issue for applications that want to delete messages for saving disk space.

This can be done but it is less than efficient. We played some hokey tricks like this to get the ES akka.persistence adapter working

 

--

Studying for the Turing test

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Patrik Nordwall]

Hi Greg,

In latest Akka Persistence 2.3.4 we have removed (deprecated at first) channels and delete of individual events. This means that journals will not have to implement the troublesome methods.

Delete of all events up to a sequence number is still supported.

/Patrik

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[Greg Young]

Thats great it will drastically clean up our implementation. We also have a native delete up to seq operation :) Can we control how often that is called?

[Patrik Nordwall]

On Wed, Jul 2, 2014 at 3:27 PM, Greg Young <gregor...@gmail.com> wrote:

Thats great it will drastically clean up our implementation. We also have a native delete up to seq operation :)

Glad to hear that. 

 

Can we control how often that is called?

That is called by user code only. We don't remove things automatically.

By the way, this is the mailing list for Eventsourced. Discussion about Akka Persistence is better done at akka-user or akka-dev.