The durables.isEmpty check was due to a bug in persistAll at the time that
code was written. I think it has been fixed by now.
On Friday, April 14, 2017 at 4:54:22 PM UTC+1, ahjohannessen wrote:
>
> I am correct, try it out. We do something like this:
>
> def processEvents
> persist().) But from looking at the code for Eventsourced, it seems like
> you're probably correct. Excellent -- thanks!
>
> On Thu, Apr 13, 2017 at 8:38 PM, ahjohannessen <ahjoha...@gmail.com
> > wrote:
>
>> Use deferAsync after persistAll
>>
>> --
&g
Use deferAsync after persistAll
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message
One trick going from legacy to ES is to make initial "snapshot" migration
events in order to get data over.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the
Ryan, I suppose that works because of:
val d: ((Unit) ⇒ Unit) ⇒ Unit = defer()
?
On Friday, July 17, 2015 at 4:00:43 PM UTC+1, Ryan Bair wrote:
Hi Andrew,
There is the defer method which handles this case rather nicely.
case Message =
val events = ...
persist(events)
defer() { _
Andrew, I have also run into that and never paid much attention to defer,
solved my problem in a rather clumsy way:
private def processEvents(events: Seq[DomainEvent], cm: CommandMessage)(done: ⇒
Unit): Unit = {
val durables = events map { e ⇒
DurableEvent(e, pid).causedBy(cm)
}
If that defer works as explained, then I can reduce my code to this:
...
val durables = events map { e ⇒
DurableEvent(e, pid).causedBy(cm)
}
persist(durables)(applyEvent)
defer()(_ ⇒ done)
...
That's rather nice :)
On Friday, July 17, 2015 at 8:04:54 PM UTC+1, ahjohannessen wrote
Should the PersistentId be different for all the different actors? Like
order-number-1, order-number-2 etc... to order-number-1000
Yes, if you choose to use several actors. One does not, in general, have
multiple persistent actors with the same persistence identifier.
On Friday, June 26, 2015
I might have misunderstood your point, please elaborate what you mean. Is
it to DRY out things like event = removeCity(event.cityId)?
On Friday, June 26, 2015 at 9:31:45 AM UTC+1, ahjohannessen wrote:
Validation in the cmd handler is one thing - receiveRecover and cmd
handlers might use
Validation in the cmd handler is one thing - receiveRecover and cmd
handlers might use the same apply state, but what it seems you suggest is
that there is no difference between applying events and creating events.
Big difference wrt. validation and replying in persist callback.
On Friday,
Prakhyat, it is really simple. Just wrap the message in case class
ViewRead(msg: Any, sequenceNr: Long, persistenceId: String) and maintain a
pointer of last seen sequenceNr per persistent actor, i.e. persistenceId. Then
you can start CatchUp from that.
--
Read the docs:
Prakhyat, perhaps I was a bit unclear. However, my approach is to define a def
consumer on CatchUp and usually have a persistent actor own that view and
maintain a pointer to sequenceNr plus having the view sending ViewRead to the
consumer.
--
Read the docs: http://akka.io/docs/
Prakhyat, I use something like the following code, (greatly simplied), for
starting a view from a specific sequence number:
package demo
import scala.concurrent.duration._
import akka.actor.{ActorLogging, ActorRef, Props}
import akka.persistence.PersistentView
object CatchUp {
case class
Alessandro, I solved that issue by using weave
- https://github.com/zettio/weave - A quick experiment by using a akka
cluster demo made by Nepomuk Seiler
- https://github.com/muuki88/activator-akka-docker - I got a cluster
running with docker containers:
sudo weave launch 10.0.0.1/16
sudo
of the next persistence sprint, would you mind doing that? Thanks!
On Fri, Sep 12, 2014 at 12:45 PM, ahjohannessen ahjoha...@gmail.com
javascript: wrote:
Hi,
Would it not be a good idea to have leveldb as a separate dependency a la
akka-persistence-leveldb? I know one can exclude dependencies
Hi,
Would it not be a good idea to have leveldb as a separate dependency a la
akka-persistence-leveldb? I know one can exclude dependencies,
but I am thinking that most people will use something else for production.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hi Martin,
On Thursday, August 28, 2014 8:01:43 AM UTC+1, Martin Krasser wrote:
In your summary, the only query command type pre-defined in
akka-persistence is QueryByPersistenceId. I'd find it useful to further
pre-define other query command types in akka-persistence to cover the most
Hi Roland,
On Thursday, August 28, 2014 11:00:17 AM UTC+1, rkuhn wrote:
Concerning types I assume that there is an implicit expectation that they
work like types in Java: when I persist a ShoppingCartCreated event I want
to see it in the stream for all ShoppingCartEvents. This means that the
On Tuesday, August 19, 2014 9:53:46 AM UTC+1, Martin Krasser wrote:
I agree, but recent discussions were about how to join events from several
topics/streams that a PersistentView receives (e.g. all events of an
aggregate type or based on a user-defined join/query)...
I think the most
persistent actor as
a journal,
thus getting a tag + seqNr, and use persistent views to what I otherwise
would
use a normal persistent actor for, e.g. as in this sketch:
- https://gist.github.com/ahjohannessen/70381de6da3bde1c743e
and use snapshotting to reduce recovery time of persistent views
On Thursday, August 7, 2014 7:34:15 PM UTC+1, Vaughn Vernon wrote:
I vote that you need to have a single sequence across all events in an
event store. This is going to cover probably 99% of all actor persistence
needs and it is going to make using akka-persistence way easier.
If that was
Hi Patrik,
I think it is enough to use same tag for all events of a particular type of
persistent actor instead of allowing different tags per event. What is
important is that it is possible to track the logical position (offset) for all
events with the same tag.
--
Read the docs:
I'm not sure I understand this requirement. Do you ask for full ordering among
all events with the same tag? That is not possible for scalability reasons.
So, you do not think it is possible for a journal to maintain a logical
position per topic / tag ?
Time stamps, logical clocks, or such,
How do you define the order? Is it based on time stamps in the persistent
actors? Is it based on some feature in the backend store?
I do not think time stamp precision is important for this, I would imagine a
logical position / offset as EventStore/Kafka do. I imagine those are based on
Lastly, would you mind creating a ticket for the 2) feature?
Thanks in advance, have a nice weekend :-)
Sure Konrad, however I think I'll wait a little bit because getting input
from the likes of Greg and Martin helps formulate the issue more clearly.
It would be awesome to get the
Greg, exactly. I think Akka Persistence having such capabilities would make
it even more awesome and useful.
Thanks for chiming in, your opinion on this is very much appreciated.
Ashley, thanks for the kind words. Glad to learn that my worries are not
completely mental and just my own
Ashley, perhaps this might be useful for you.
import scala.concurrent.duration._
import akka.actor._
import benefits.configuration.Settings
/* Message used by `Child` to signal `Parent` it should
* be passivated by way of PoisonPill after a configurable
* idle time.
* */
case object Passivate
I think it would be useful to have a setting a la
keep-at-most-nr-snapshots.
I believe that is beneficial for all users, you should create an issue at
github :)
On Saturday, July 26, 2014 9:08:39 AM UTC+1, Rohit Kumar Gupta wrote:
Hello,
I am using akka persistence (akka 2.3.4 play 2.3.1)
I think that Akka Persistence lacks in some areas that are essential for
using CQRS
with DDD aggregates effectively (without a lot of pain):
1) Ability to read persistent actor messages by type of Actor. This can be
as simple
as a key prefix that represents a category/tag/topic,
e.g.
On Wednesday, July 16, 2014 7:09:06 AM UTC+1, Martin Krasser wrote:
I think it makes sense to go into that direction and to require that all
journal backend stores support that, so that user-defined event streams can
be consumed both Akka-internally and by external consumers (that directly
Here is an example of how you could store stuff in a list using a
persistent actor.
class Example(id: String) extends EventsourcedProcessor {
import Example._
override val processorId = id
var messages = Vector[String]()
def receiveCommand: Receive = {
case
://github.com/akka/akka/issues/15231) which might be of interest in
this context. My motivation here is to not remove needed functionality
without improved replacement.
Regards,
Roland
9 maj 2014 kl. 12:15 skrev ahjohannessen ahjoha...@gmail.comjavascript:
:
Hi Roland,
We use Channel
Hi,
This might be what you are looking for:
https://github.com/krasserm/akka-persistence-testkit
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
Hi Roland,
We use Channel in conjunction with Eventsourced Processor (EP) in our
applications in receiveRecover.
It would be sad to see it go away without a reasonable alternative.
One scenario in our apps is that we use DDD/ES and have a lot of EPs of
same type, e.g. 1 instances,
that
You could use a correlationId on your commands and events, and then store
metadata in some other place along with the correlationId before entering
the domain.
On Tuesday, April 22, 2014 10:06:47 PM UTC+1, Ramon Buckland wrote:
Hi All,
Before I go and wind back my code change to my
.x) should also be usable with newer versions of akka as
explained in the akka migration
guidehttp://doc.akka.io/docs/akka/2.3.2/project/migration-guide-2.2.x-2.3.x.html#akka-sbt-plugin_is_Removed
.
B/
On 10 April 2014 at 23:25:22, ahjohannessen
(ahjoha...@gmail.comjavascript:)
wrote
Thanks :)
btw, is akka-sbt-plugin for 0.13.x - 2.3.x released somewhere?
On Wednesday, April 9, 2014 2:16:01 PM UTC+1, Patrik Nordwall wrote:
*Dear hAkkers,*
We—the Akka committers—are pleased to be able to announce the availability
of Akka 2.3.2. This is the second maintenance release of
A big thank you to the Akka team for your outstanding efforts. A lot of
exciting stuff has happened for Akka in 2013, that's for sure, but
something tells me that 2014 is going to be even better :)
Merry Christmas Happy New Year to all of you great people :)
On Thursday, December 19, 2013
38 matches
Mail list logo
