Eventsourced

[ami...@nrifintech.com]

Hi Martin and Team,

Thanks for the eventsourced framework. We plan to use eventsourced in our application.

However we have a couple of questions, we plan to persist the messages in LevelDb or MongoDB.

If I am persisting a message in LevelDb, can I query the event later on to check if it was successfully processed?

Suppose there are 3 events denoting state of a employee, JOINED, WORKING, LEFT.

if the last event is LAST , can I also query the previous state of the Employees? Means what state he was in before he left with levelDB?

How good is eventsourced mongoDB support at this point ?

Regards,

Amit

[Martin Krasser]

Hi Amit,

On 24.10.13 08:40, ami...@nrifintech.com wrote:

Hi Martin and Team,

Thanks for the eventsourced framework.

You're welcome, thanks for your interest.

We plan to use eventsourced in our application.

Do you also know about akka-persistence? It's the successor of eventsourced and milestone 1 has already been released.

However we have a couple of questions, we plan to persist the messages in LevelDb or MongoDB.

If I am persisting a message in LevelDb, can I query the event later on to check if it was successfully processed?

A processor only receives a message, if it has been successfully written to the journal. It will never receive a message that could not be written.

Suppose there are 3 events denoting state of a employee, JOINED, WORKING, LEFT.

if the last event is LAST , can I also query the previous state of the Employees? Means what state he was in before he left with levelDB?

You do that by replaying messages and analyze the replayed message stream in whatever way you like.

How good is eventsourced mongoDB support at this point ?

It's used in production.

Regards,

Amit

--
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/groups/opt_out.

-- 
Martin Krasser

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

[ami...@nrifintech.com]

Hi Martin,

Thanks for the answers they are really helpful. We intend to complete the work by December, I think akka will be production ready by December, so we cant use it.

I need one more answer,if there is an Employee event, do I need to assign it a unique ID.

If yes, can I find all historical states of the employee with that ID from levelDB?

If a data is stored in MongoDB can I query the MongoDB objects like I do normally? Assuming I have to give the ID ?

Regards,

Amit

[Martin Krasser]

On 24.10.13 10:55, ami...@nrifintech.com wrote:

Hi Martin,

Thanks for the answers they are really helpful. We intend to complete the work by December, I think akka will be production ready by December, so we cant use it.

I need one more answer,if there is an Employee event, do I need to assign it a unique ID.

This is not required by eventsourced.

If yes, can I find all historical states of the employee with that ID from levelDB?

The journal only contains changes. If you want to reconstruct the historical state of an entity, you'll need to replay up to the corresponding sequence number in the past.

If a data is stored in MongoDB can I query the MongoDB objects like I do normally? Assuming I have to give the ID ?

See previous answer.

[ami...@nrifintech.com]

I am sorry if I am being obtuse, but I cant understand the sequence Number concept, reading the docs. So for every message a sequence number is generated ?

Regards,

Amit

[Martin Krasser]

On 24.10.13 11:42, ami...@nrifintech.com wrote:

I am sorry if I am being obtuse, but I cant understand the sequence Number concept, reading the docs. So for every message a sequence number is generated ?

yes

[ami...@nrifintech.com]

Ahh...okay...so every state a unique Sequence Number will be generated...which I can use to replay the events...

Shouldnt these sequence numbers help us query the normal mongo way to find the object from there, without involving eventsourced...

What I want more specfically to directly find a object by sequcne from mOngoDb

Thanks for your answers again.

[Martin Krasser]

On 24.10.13 12:05, ami...@nrifintech.com wrote:

Ahh...okay...so every state a unique Sequence Number will be generated...which I can use to replay the events...

Shouldnt these sequence numbers help us query the normal mongo way to find the object from there, without involving eventsourced...

What I want more specfically to directly find a object by sequcne from mOngoDb

You can find the event by sequence number in MongoDB but not the (domain) object (i.e. the projection of these events). These are only in-memory (= state of processor).

[ami...@nrifintech.com]

Ahh..okay..let me go back and look again at the things..finding the events itself is okay..may be we can do it manually...Is there a good sample project of eventsourced in java?

[Duncan DeVore]

Hi Amit,

Another thing to consider is that while you can pull the event out by sequence number, it will be in binary format. Eventsourced handles the serialization/de-serialization internally. If you bypass the processor then you would have to de-serialize the event yourself.

The preceding email message may contain confidential information of Viridity Energy, Inc. It is not intended for transmission to, or receipt by, any unauthorized persons. If you have received this message in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the message.

[Greg Young]

I think many understandings about the model are happening. Perhaps a doc on event sourcing and it's various usages could be helpful

The preceding email message may contain confidential information of Viridity Energy, Inc. It is not intended for transmission to, or receipt by, any unauthorized persons. If you have received this message in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the message.

--

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/groups/opt_out.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Martin Krasser]

On 24.10.13 22:44, Greg Young wrote:

I think many understandings about the model are happening. Perhaps a doc on event sourcing and it's various usages could be helpful

We started cover this in the akka-persistence event sourcing section. More to come ... and contributions or concrete suggestions for improvement are welcome, of course.

[Ivano Pagano]

It would be really great to have some examples of how to replay the event log to some point and move over from that in the documentation, or even as a blog (series?).

One of the things I really find interesting of the whole event-sourcing approach is this ability to change history (more precisely how to rebuild your system state as if the event sequence had been different).

This could be a huge help in correcting bugs and applying the fix to past events, or to add new features that could be replayed on the whole system.

A part of this is enabled by changing the actor's inner logic in reaction to commands and replaying the event log, but this approach is limited to existing commands.

If new events/commands are to be retroactively applied it's necessary to be able to change the event log itself (or at least replay it starting from a fixed event)

What do you think? Is there already some resource or documentation that examines this use case?

Thank you for the awesome work

Ivano

To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Martin Krasser]

Hi Ivano,

I'm not aware of a concrete example covering the whole use case you described, but once akka-persistence is officially released, I'll try to implement all examples discussed in Event Sourcing and Retroactive Events with it (which also covers your use case).

Cheers,
Martin

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/groups/opt_out.

-- 
Martin Krasser

blog:    http://krasserm.blogspot.com

[Ivano Pagano]

Great, I'll eagerly await (asynchronously....) for that!

thanks

Ivano

[HP]

You can already do this with EventSourced.  You can use protobufs to define your events so you can add/update events and still be able to read old events.  As for replaying events, you can rebuild state on recovery from start so this gives you the ability to "fix" any logic which is maintained within your actor by processing the events again.

As for starting from event X instead of reprocessing all events, you can take snapshots.  One thing I have not really played with is the idea of offline snapshots, e.g. if you are going to rebuild state, you can rebuild it offline first and then restart the online application after a code update and have it pick up the offline snapshot and go from there.

-Hiral