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,
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
.
Kind regards,
Olger
On Fri, May 8, 2015 at 10:58 PM, Richard Rodseth rrods...@gmail.com
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 ol...@spectare.nl wrote:
Hi Alejandro,
You have a number
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
but the history and code is there.
/Magnus
Den fredag 24 april 2015 kl. 16:43:46 UTC+2 skrev Olger Warnier:
Well,
I found that the sequence numbers are actually generated on a per
persistent actor instance basis.
So that makes replay for a single aggregateId based with limits
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
on the 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 aggregateId (more or less
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 create a
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
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-
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
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 UTC+5:30, Olger Warnier wrote:
Hi Prakhyat,
I'd use
code. Do you recommend using ask?
-Prakhyat M M
On Friday, 26 September 2014 16:23:12 UTC+5:30, Olger Warnier wrote:
Hi Prakhyat,
When you use the ‘ask’ / pipeTo pattern, it can all be sync, kills your
performance though. So when the load won’t be too high, that may be an
option
, Olger Warnier wrote:
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
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
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 passes on the right events to the drools
actor.
Bit
+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 may get
better answers in the DDD/CQRS group.
To give you some options: You
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
), 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 amait...@gmail.com wrote:
Thanks for your post Olger.
On Monday, 8 September 2014 14:11:14 UTC+8, Olger Warnier wrote:
Events are assigned
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/
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
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
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 regards,
Olger
On Friday, September
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
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
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
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
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
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
On Tue, Jul 1, 2014 at 6:05 PM, Patrik Nordwall patrik@gmail.com
javascript: 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 ol...@spectare.nl
javascript
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
that arguments to its constructor must come from the ActorSystem
itself, hence from configuration as you also figured out. You can use
system.dynamicAccess in order to reflectively create your factory from a
fully qualified class name.
Regards,
Roland
On Fri, May 9, 2014 at 6:14 PM, Olger Warnier
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
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:
The User actor persist
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 ol...@spectare.nljavascript:
wrote:
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 ol...@spectare.nlwrote
AM UTC+2, Patrik Nordwall wrote:
On Tue, Apr 22, 2014 at 11:32 AM, Olger Warnier
ol...@spectare.nljavascript:
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 ol...@spectare.nlwrote:
On Sunday, April 20, 2014 4
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 ol...@spectare.nl javascript:
:
Hi Martin,
Had to think about it a little, hereby my follow up. (hope you
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 ol...@spectare.nljavascript:
wrote:
Hi Patrick,
Sounds like an interesting approach, storing some meta-data at the view
may help to check / show the reliability
39 matches
Mail list logo
