Without knowledge of your domain, the tag would be something like
"Customer" and the ID would be customer_456 (or a UUID)
any reason you like to attach the account_123 upfront ? Looks like some
kind of relation between account and customer.
On Tuesday, May 24, 2016 at 8:37:22 PM UTC+2, code...
I'd suggest to use tags per aggregate root and have the account id as the
persistenceId.
when you use cluster sharding, that gives a great option to 'instantiate' a
specific instance of the aggregate root and for the query side you use the
tags.. works quite well in practice.
kind regards,
Hi Paul,
You can indeed use a View to store your data in such a way that it works
for your queries.
With the Akka 2.3.x you need to create a view for every aggregate root
("Client" for your situation). That adds some overhead in handling. (as you
need to trigger these views when changes have
ire.
Kind regards,
Olger
On Fri, May 8, 2015 at 10:58 PM, Richard Rodseth
wrote:
> Hi Olger
> Could you please elaborate a bit on your appoach? I'm not sure I follow.
> Thanks.
> On Fri, May 8, 2015 at 4:17 AM, Olger Warnier wrote:
>> Hi Alejandro,
>>
>> You
Hi Alejandro,
You have a number of options
- when you have a single persistence Id, write a view for that
- when you want to aggregate events of several persistence ids, you can do so
via the event store (approach of Martin (with Kafka) and Greg (event store) )
Or you can aggregate the
ent stream buffer that sorts events based on the persist
>>> timestamp
>>>before emitting messages.
>>>3. *Shared sequence ordering: *basically your original idéa combined
>>>with event stream buffer. You include an extra field which has sequence
&g
way to
solve this (some kind of atomic sequence generator shared between
aggregates ?)
On Friday, April 24, 2015 at 10:42:04 AM UTC+2, Olger Warnier wrote:
>
> Hi Roland / List,
>
> I am looking into an addition/mutation to the Persistency layer that
> allows storage of an aggre
Hi Roland / List,
I am looking into an addition/mutation to the Persistency layer that allows
storage of an aggregateId (more or less the whole 'tag' idea without being
able to have multiple tags to start out with) with a replay (for the view)
based on that aggregateId. (bit like the DDD Aggre
Hi List,
with akka stream M2 you could do a onComplete on an element in the stream.
So when the whole thing was finished, it was possible to handle the result
and exit (for instance)
In M4 this seems to have changed. What is the advised way to do something
similar with the M4 release ?
code
Hi Martin,
In my experience, the last update for a specific sequence number is kept.
With a replay, you'll end up with a mixed state.
Kind regards,
Olger
On Friday, November 14, 2014 1:16:27 PM UTC+1, Martin Jöhren wrote:
>
> Hi,
>
> what would happen when two different servers somehow creat
Hi Anders,
Persisting events in a PersistentActor is not much different than
persisting your ORM objects in some kind of service from a separation of
concerns perspective.
This assumes that your separation of concerns 'concern' is around this
area.
I've tried to answer your questions a with
Hi Prakhyat,
I've the same situation (this is discussed in length in other topics)
The solution at this moment is to create another persistent actor that
stores the fact that change has happened to on of your other persistent
actors (probably the aggregate root)
Thereafter you add a view that
Hi Mike,
Did you look at the distributed worker pattern ?
See: http://typesafe.com/activator/template/akka-distributed-workers
That may be a better match looking at your use case.
Kind regards,
Olger
On Tuesday, September 30, 2014 11:41:59 PM UTC+2, Michael Kohout wrote:
>
> Hi Folks-
>
>
+= 1
> println(s"view received persistent ${payload} (num replicated =
> ${numReplicated})") case payload => println(s"view received not persitent
> ${payload}") } }
>
> Do you suggest to check value of "recoveryRunning" inside
>
> On Friday, 26 S
us
> issues. What are your thoughts on this? This will help me a lot, if at all
> I will start using "ask" in my code. Do you recommend using "ask"?
>
> -Prakhyat M M
>
> On Friday, 26 September 2014 16:23:12 UTC+5:30, Olger Warnier wrote:
>>
>> Hi Pr
ery bounded
> context is different application deployed in different JVM's. The cluster
> sharding again wouldn't help.*Also how to do updates in sync when bounded
> contexts are deployed in different JVM's?*
> -Prakhyat M M
> On Friday, 26 September 2014 00:38:58
Hi Prakhyat,
On Wednesday, September 24, 2014 8:56:46 PM UTC+2, Prakhyat Mallikarjun
wrote:
>
> Hi Björn,
>
> Thanks again. I am bit clear now but still have some gaps.
>
> [Björn]The persistent view is meant to be a view of the state built up
> from the events of a persistent actor, not just a
Hi Prakhyat,
I'd use persistent actors with cluster sharding.
You can start the the ClusterSharding system for different typenames that
reflect a bounded context - or - a single aggregate root (in our situation)
like:
ClusterSharding(system).start(
typeName = AggregateRootNameHere
And h
ay, 8 September 2014 23:19:29 UTC+5:30, Olger Warnier wrote:
>>
>> Hi Prakhyat,
>>
>> Vaughn Vernon has some articles an how to go about DDD and akka see
>> https://vaughnvernon.co for the details.
>> Your questions about the way to interact with business experts
ating event and after receiving command.
> -Prakhyat M M
> On Monday, 8 September 2014 23:07:03 UTC+5:30, Olger Warnier wrote:
>>
>> Hi Prakhyat,
>>
>> Wrap an a tor around it, you be able to integrate it in a number of ways.
>> An option is to build a view that passe
Hi Prakhyat,
Vaughn Vernon has some articles an how to go about DDD and akka see
https://vaughnvernon.co for the details.
Your questions about the way to interact with business experts may get better
answers in the DDD/CQRS group.
To give you some options: You may write a DSL used inside the p
Hi Prakhyat,
Wrap an a tor around it, you be able to integrate it in a number of ways. An
option is to build a view that passes on the right events to the drools actor.
Bit of a broad answer, hard to be more specific
Kind regards,
Olger
--
>> Read the docs: http://akka.io/docs/
), I’ll remove this as it will become a bottleneck in
the cluster sharded setup.
Kind regards,
Olger
On Mon, Sep 8, 2014 at 8:18 AM, Ashley Aitken wrote:
> Thanks for your post Olger.
> On Monday, 8 September 2014 14:11:14 UTC+8, Olger Warnier wrote:
> Events are assigned the sa
Hi Ashley,
Events are assigned the same number as each instance starts counting in the
same way. It appears that the last one written with a specific sequence number
is eventually kept.
In my situation, I've solved this by using a cluster singleton for this
persistent actor.
Kind rega
Hi guys,
simple question: is it expected that exactly 1 PersistentActor that makes
use of a specific persistenceId is active ?
In order to get all changes of my AggregateRoot, I've build a publisher
that tells that this aggregate has changed. By using a single
persistenceId, it's possible to
Hi Jitendra,
You may want to look at the spray client, a nice piece of work that helps
you to call http based services in an async way.
Kind regards,
Olger
On Friday, September 5, 2014 10:53:18 AM UTC+2, jitendra shelar wrote:
>
> Hi,
>
> I am newbie to Akka.
> I am developing a payment ga
On Friday, September 5, 2014 5:14:22 PM UTC+2, Olger Warnier wrote:
>
> Hi Jitendra,
>
> You may want to look at the spray client, a nice piece of work that helps
> you to call http based services in an async way.
>
Oh: It's based on akka actors..
>
> Kind
Hi Roland,
This will certainly simplify my code. So from my side it will be a good
'start' to experiment with these additions in practice and see what's
missing.
Kind regards,
Olger
On Friday, September 5, 2014 9:49:20 AM UTC+2, Martin Krasser wrote:
>
>
> On 05.09.14 09:09, Roland Kuhn
Hi Roland,
great conclusion, with everything said till now in mind. I'd like to
mention a view points and like to hear if this matches your thoughts:
The QueryByTypeDeterministic(type, from, to) mentioned by Martin matches
with the way I've been using DDD+CQRS for last 2 years.
Meaning that t
Quite a read on a phone during my holidays. Very insightful and adds a lot of
considerations around the different topics.
I'd like to mention that the current construct of the persistent view is very
helpful in decoupling. I can create new listeners (e.g. PersistentView) based
on the events pe
Quite a read on a phone during my holidays. Very insightful and adds a lot of
considerations around the different topics.
I'd like to mention that the current construct of the persistent view is very
helpful in decoupling. I can create new listeners (e.g. PersistentView) based
on the events pe
Hi Prakhyat,
With DDD and CQRS, the state changes storage and publication are key part of
the architecture. When you don't need the DDD part, you could use a persistence
processor that handles the transactions (still possible to do cqrs in that way)
Although your story makes me wonder, when yo
One small note for people that may run into this issue:
Our project uses the leveldb in a shared mode 'native = off' in our
multi-jvm test setup.
(inmem in our inproc setup)
It appears that the leveldb dependency gives issues in this setup.
The whole thing is described here
https://github.com
> On Tue, Jul 1, 2014 at 6:05 PM, Patrik Nordwall > wrote:
>
>> Let's continue with questions at akka-user.
>> /Patrik
>>
> Good idea... The groups interface confuses me once in a while.
>
>>
>> On Tue, Jul 1, 2014 at 5:53 PM, Olger Warnier
Nice, thanks :)
A small question, the EventsourcedProcessor will be replaced by the
PersistentProcessor (as my compile messages tell me :) )
It seems that it's not available in the 2.3.4 source, is that right ?
The documentation states the use of the PersistentActor instead of the
PersistentPro
Hi Erich,
Different options are discussed the Views with multiple processors topic
see:https://groups.google.com/forum/#!topic/akka-user/dhyZ-WpwPz4
I've chosen to use a special event that is stored in the eventstore that
aggregates all changes in the different EventsourcedProcessors.
These 'c
gt;
> Roland
>
>
>
> On Fri, May 9, 2014 at 6:14 PM, Olger Warnier
> > wrote:
>
>> Hi All,
>>
>> I try to create an extension that needs a parameter in order todo it's
>> job.
>>
>> extensions are created like:
>>
>> o
Hi All,
I try to create an extension that needs a parameter in order todo it's job.
extensions are created like:
override def createExtension(system: ExtendedActorSystem) = {
new MyExtension(system)
}
And I'd like have something like 'new MyExtension(system,
myCustomParameter: AType)'
On Friday, May 9, 2014 5:58:42 PM UTC+2, Paweł Kaczor wrote:
> On Friday, May 9, 2014 4:37:16 PM UTC+2, Olger Warnier wrote:
>
>> On Friday, May 9, 2014 4:29:32 PM UTC+2, Paweł Kaczor wrote:
>>
>>> On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
On Friday, May 9, 2014 4:29:32 PM UTC+2, Paweł Kaczor wrote:
> On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
>
>>
>>
>> The User actor persist FirstNameChanged, and inside the persist block it
>> sends a Persistent(FirstNameChanged) message to the AllUsers Processor. On
>> t
AM UTC+2, Patrik Nordwall wrote:
>
>
>
>
> On Tue, Apr 22, 2014 at 11:32 AM, Olger Warnier
>
> > wrote:
>
>>
>> On Monday, April 21, 2014 9:07:03 AM UTC+2, Patrik Nordwall wrote:
>>
>>> On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier wrote
On Monday, April 21, 2014 9:07:03 AM UTC+2, Patrik Nordwall wrote:
>
> On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier
> > wrote:
>>
>> On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
>>
>>> On Sun, Apr 20, 2014 at 2:47 PM, O
On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
>
>
> On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier
> > wrote:
>
>> Hi Patrick,
>>
>> Sounds like an interesting approach, storing some meta-data at the view
>> may help to
-data (processor-id, seq-no,timestamp) and have a view that creates
> sub-views on demand from the replayed meta-data. The sub-views would
> forward to the parent aggregated view.
>
> /Patrik
>
> 19 apr 2014 kl. 20:46 skrev Olger Warnier
> >:
>
>
> Hi Martin,
>
&g
. Using EventsourcedProcessor, I'd expect that I need
to replay everything for all instances and pick the one that I need for
processing at that moment. (this can of course be optimized with snapshots
and something like memcached). This appears to be a performance hit as I
feel it.
>
&
Hi Martin,
I'm currently working on view composition using the brand new akka-stream
> module. Basic idea is to make views stream producers and to use the
> akka-stream DSL to merge message/event streams from several producers into
> whatever you need. See also
> https://twitter.com/mrt1nz/s
Hi Patrick,
In a situation with a lot of (Eventsourced)Processors and having a View to
store certain (view) state into a database (or other storage), You need to
take care of the way connections to these storage are managed, especially
when it is used together with cluster sharding.
A single
47 matches
Mail list logo
