KC | 30 Sep 02:46 2012
Picon

One of the new buzz phrases is "Event-Sourcing"; is Haskell suitable for this?

http://martinfowler.com/eaaDev/EventSourcing.html

http://martinfowler.com/articles/lmax.html

--

-- 
--
Regards,
KC
Brandon Allbery | 30 Sep 02:59 2012
Picon

Re: One of the new buzz phrases is "Event-Sourcing"; is Haskell suitable for this?

On Sat, Sep 29, 2012 at 8:46 PM, KC <kc1956 <at> gmail.com> wrote:
http://martinfowler.com/eaaDev/EventSourcing.html

STM?  And I believe there's work on the debugger in ghci to "run programs backwards".

--
brandon s allbery                                      allbery.b <at> gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Alberto G. Corona | 30 Sep 03:22 2012
Picon

Re: One of the new buzz phrases is "Event-Sourcing"; is Haskell suitable for this?

It´´s a very iteresting concept.

The Workflow Monad transformer [1], in Control.Workflow perform
logging and recovery of application istate from the log created.
It has no implementation of roll-back or limited recovery upto a
point, but this is easy to implement.

It also has many inspection and synchronization primitives. It has
been used also for translating the log of a program and recovering the
state in another machine. The log  can be pretty-printed for
debugging.

[1] http://hackage.haskell.org/package/Workflow

2012/9/30 KC <kc1956 <at> gmail.com>:
> http://martinfowler.com/eaaDev/EventSourcing.html
>
> http://martinfowler.com/articles/lmax.html
>
>
> --
> --
> Regards,
> KC
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

--

-- 
Alberto.
Marcelo Sousa | 30 Sep 18:02 2012
Picon

Re: One of the new buzz phrases is "Event-Sourcing"; is Haskell suitable for this?

Hi,

On Sun, Sep 30, 2012 at 4:22 AM, Alberto G. Corona <agocorona <at> gmail.com> wrote:
> It´´s a very iteresting concept.
>
> The Workflow Monad transformer [1], in Control.Workflow perform
> logging and recovery of application istate from the log created.
> It has no implementation of roll-back or limited recovery upto a
> point, but this is easy to implement.

Is Control.Workflow similar with acid-state with respect to the way
you recovery the current state?

> It also has many inspection and synchronization primitives. It has
> been used also for translating the log of a program and recovering the
> state in another machine. The log  can be pretty-printed for
> debugging.

Can you "somehow" recover impure (IO) computations?

> [1] http://hackage.haskell.org/package/Workflow

Regards,
Marcelo

> 2012/9/30 KC <kc1956 <at> gmail.com>:
>> http://martinfowler.com/eaaDev/EventSourcing.html
>>
>> http://martinfowler.com/articles/lmax.html
>>
>>
>> --
>> --
>> Regards,
>> KC
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Alberto.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Alberto G. Corona | 30 Sep 19:15 2012
Picon

Re: One of the new buzz phrases is "Event-Sourcing"; is Haskell suitable for this?

Hi,Marcelo,

No. .Acid state is  explcitly managed by the process by means of state management primitives

In Control.Workflow the state is managed in a implicit way. 

It is a monad transformer mainly  is designed for wrapping IO computations.

the lifting primitive, step, store the intermediate result and recover the application state.

in acid state the process choose what to write in the state

in workflow the state written is the complete state of the process.

See the example in the documentation. the process , 

import Control.Workflow import Control.Concurrent(threadDelay) import System.IO (hFlush,stdout) mcount n= do step $ do putStr (show n ++ " ") hFlush stdout threadDelay 1000000 mcount (n+1) return () -- to disambiguate the return type main= exec1 "count" $ mcount (0 :: Int) >>> runghc demos\sequence.hs >0 1 2 3 >CTRL-C Pressed >>> runghc demos\sequence.hs >3 4 5 6 7 >CTRL-C Pressed >>> runghc demos\sequence.hs >7 8 9 10 11 ...
in subsequent executions the process start to execute IO computations from the last point logged:

As the documentation says  some side effect can be re-executed after recovery if the log is not complete. This may happen after an unexpected shutdown (in this case Contro-C has been pressed) or due to an asynchronous log writing policy. (see syncWrite(writing is cached).

Althoug this is not event sourcing, The logging and recovery facilities can be used for even sourcing. 

Alberto

2012/9/30 Marcelo Sousa <dipython <at> gmail.com>
Hi,

On Sun, Sep 30, 2012 at 4:22 AM, Alberto G. Corona <agocorona <at> gmail.com> wrote:
> It´´s a very iteresting concept.
>
> The Workflow Monad transformer [1], in Control.Workflow perform
> logging and recovery of application istate from the log created.
> It has no implementation of roll-back or limited recovery upto a
> point, but this is easy to implement.

Is Control.Workflow similar with acid-state with respect to the way
you recovery the current state?

> It also has many inspection and synchronization primitives. It has
> been used also for translating the log of a program and recovering the
> state in another machine. The log  can be pretty-printed for
> debugging.

Can you "somehow" recover impure (IO) computations?

> [1] http://hackage.haskell.org/package/Workflow

Regards,
Marcelo

> 2012/9/30 KC <kc1956 <at> gmail.com>:
>> http://martinfowler.com/eaaDev/EventSourcing.html
>>
>> http://martinfowler.com/articles/lmax.html
>>
>>
>> --
>> --
>> Regards,
>> KC
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Alberto.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alberto.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bardur Arantsson | 30 Sep 20:16 2012
Picon

Re: One of the new buzz phrases is "Event-Sourcing"; is Haskell suitable for this?

On 09/30/2012 02:46 AM, KC wrote:
> http://martinfowler.com/eaaDev/EventSourcing.html
> 
> http://martinfowler.com/articles/lmax.html
> 
> 

Sure, why not? See

    http://hackage.haskell.org/package/cqrs-0.8.0
and http://hackage.haskell.org/package/cqrs-example-0.8.0

for an example application.

I should note that the "cqrs" package API is by no means finalized;
there are some limitations(*) to the current implementation, but I've
not had time to actually get rid of those limitations.

(*) The major ones being the requirement for a global version number and
lack of streaming event sourcing.
Joey Adams | 1 Oct 02:32 2012
Picon

Re: One of the new buzz phrases is "Event-Sourcing"; is Haskell suitable for this?

On Sat, Sep 29, 2012 at 8:46 PM, KC <kc1956 <at> gmail.com> wrote:
> http://martinfowler.com/eaaDev/EventSourcing.html
>
> http://martinfowler.com/articles/lmax.html

This notion of "Capture all changes to an application state as a
sequence of events" sounds a lot like what John Carmack did in Quake 3
[1]:

> I settled on combining all forms of input into a single system event queue, similar to the windows message
queue. My original intention was to just rigorously define where certain functions were called and cut
down the number of required system entry points, but it turned out to have much stronger benefits.

 [1]: http://www.team5150.com/~andrew/carmack/johnc_plan_1998.html#d19981014

Gmane