Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 31 2019 19:32

    prolic on v1.10.3

    (compare)

  • Jan 31 2019 19:32

    prolic on master

    update changelog (compare)

  • Jan 31 2019 19:29
    prolic closed #176
  • Jan 31 2019 19:28
    prolic commented #186
  • Jan 31 2019 19:28
    prolic closed #186
  • Jan 31 2019 19:28

    prolic on master

    fix restarting projection durin… respect lock in memory resetting projection and 12 more (compare)

  • Jan 31 2019 16:26
    fritz-gerneth commented #189
  • Jan 31 2019 16:21
    prolic commented #189
  • Jan 31 2019 16:06
    sandrokeil commented #189
  • Jan 31 2019 15:31
    grzegorzstachniukalm synchronize #186
  • Jan 31 2019 15:23
    kamil-nawrotkiewicz edited #76
  • Jan 31 2019 15:22
    kamil-nawrotkiewicz edited #76
  • Jan 31 2019 15:22
    kamil-nawrotkiewicz opened #76
  • Jan 31 2019 15:19
    grzegorzstachniukalm synchronize #186
  • Jan 31 2019 15:09
    grzegorzstachniukalm synchronize #186
  • Jan 31 2019 13:54
    coveralls commented #186
  • Jan 31 2019 13:48
    mrook commented #189
  • Jan 31 2019 13:41
    prolic commented #189
  • Jan 31 2019 13:40
    prolic commented #189
  • Jan 31 2019 13:31
    fritz-gerneth commented #189
Fábio Carneiro
@fabiocarneiro
I wanted to give a try to prooph/event-store-client:1.0.0@RC but it depends on prooph/event-store:8.0.0@RC. In the current state, it is hard/impossible to install the rest of the packages.
Fábio Carneiro
@fabiocarneiro
I've been a bit distant from PHP for a while. I understand now that you are focusing on other fronts. I asked the activity question because the last 8.x RC was released in July 2019 and that paired with the lack of messages here made me wonder if it was no longer maintained.
Sascha-Oliver Prolic
@prolic
@fabiocarneiro use dev-master
Zacharias Luiten
@netiul
Regarding EventEngine, when I need to confirm whether an e-mailadress is not in use (by another user) when executing a command "registerUser", I think I should configure a controller to handle the command instead of an aggregate function right?
Sascha-Oliver Prolic
@prolic
Not an eventengine user here, but I don't think so
Zacharias Luiten
@netiul
Hm, there's also a thing called preprocessor
But I need to look up what it actually can do
Alexander Miertsch
@codeliner
@netiul passing a command to a controller is mostly used when you have an external command that triggers multiple internal commands. In that case a controller receives the external command and coordinates work by dispatching internal ones
A command preprocessor is comparable to a request middleware. It receives a command, maybe modifies it and passes it on to the next preprocessor or finally to the aggregate
For your email address example the easiest option is to pass a service into the aggregate function:
$eventEngine->process(Command::REGISTER_USER)->provideService(MyEmailAddressLookupService::class)->handle(....)
MyEmailAddressLookupService::class is loaded from the DI container and passed as an argument to the aggregate function.
Alexander Miertsch
@codeliner
Attention! Advanced Topic The "best" way would be to follow the advice from the docs and take care of your functional core. A EmailAddressLookupService needs to perform read I/O (especially query a database for existing email address). Such operations should be avoided in a functional core and be handled in the application layer instead. Therefor you can also use a ContextProvider instead of a service. See the docs
A context provider is invoked by Event Engine before a command is passed to an aggregate. Whatever is returned by the context provider (should be some kind of immutable state) is passed as an argument to the aggregate function. This way read I/O happens outside of the domain layer (the functional core)
Zacharias Luiten
@netiul
Great stuff @codeliner. You're an excellent teacher.
I completely missed the docs on functional core
Alexander Miertsch
@codeliner

thx @netiul

Unfortunately, the docs are not complete and lack a lot of details. The reason is, that we never defined a clear scope for Event Engine.
1) It started as a workshop framework to hide a lot of implementation details and provide a very descriptive interface instead so that people can learn CQRS/ES step by step.
2) Then it somehow turned into our company framework because we recognized that speed of development increases a lot with Event Engine.
3) Then we started to think about an Event Engine platform meaning that even the infrastructure is abstracted away (and managed by us)
4) In the early days of planning the platform we had the idea to take the abstractions one level higher and combine them with ideas from Event Storming and Event Modeling. So basically we asked us the question if it would be possible to generate code from an event map that is executed by Event Engine.
5) And that's the experiment we are running now. We're almost ready to share it with you guys. If you look into into the Event Engine org on Github: https://github.com/event-engine you'll notice many new code generator related packages. We're currently organizing our internal prototypes into open source libraries that can be used together with our tool InspectIO to run remote Event Storming sessions and generate source code without even leaving the tool.
6) A question I cannot answer yet is, how our results will effect the future of Event Engine? IMO visual modeling combined with a code generator is extremely powerful . Even more powerful than Event Engine. Because you move the abstractions out of the code to a visual level. The code itself can be more basic and can be optimized for other characteristics. Something we need to try and experiment with. And I hope we can do it all together next year, once we published the open source stuff and provided some guidelines how to use it.

Zacharias Luiten
@netiul
Very nice :)
Zacharias Luiten
@netiul
I've really started to like the discolight container approach. It has a few limitations though which I address here event-engine/discolight#2 and event-engine/discolight#3
What do you guys think?
Fábio Carneiro
@fabiocarneiro
What is the plan for https://github.com/prooph/event-sourcing on event-store 8.x? What happens with classes like AggregateRepository?
Sascha-Oliver Prolic
@prolic
@fabiocarneiro they will be gone, we'll provide some blueprints to roll your own instead, see https://github.com/prooph/documentation/blob/master/event-store-client/blueprints.md
note: docs are not yet finished, hope to get to it soon
Fábio Carneiro
@fabiocarneiro
Idk, feels a bit weird to provide code that can't be used directly. It's all cool that people learn how to do it (not that it was hard to inspect the fw code before), but the convenience of having this ready wins imho.
@prolic thanks for the reply :)
Sascha-Oliver Prolic
@prolic
from the docs:
In fact, we recommend not using any framework or library as part of your domain model, and building the few lines of code needed to implement a left fold yourself - partly to ensure understanding and partly to keep your domain model dependency-free.
I've seen already many projects where they customized those parts to better fit their needs.
Alexander Miertsch
@codeliner
same here and it makes a lot of sense.
Fábio Carneiro
@fabiocarneiro
@prolic I did read that and think it is a reasonable motivation, but I don't think anyone was forced to use event-sourcing package before. When the code is properly designed, often it is already customizable.
I would also add that it is a bit of a stretch to say implementing an interface that exposes events from your aggregate is not keeping your model dependency-free. Regardless of frameworks, you will always need to do something like that in one way or another. There will always be a dependency on something, and if you wrote that dependency or not, is not that relevant.
I have been working with the Axon Framework on kotlin for a while, and the approach is usually using annotations (not a big fan). I have to say I miss a lot the approach Prooph has/had.
I think apart from the additional maintainer effort, getting those "blueprints" and transforming them into a library would not hurt anyone.
Alexander Miertsch
@codeliner
@fabiocarneiro the maintainer effort is the problem
Fábio Carneiro
@fabiocarneiro
@codeliner ¯_(ツ)_/¯
Sascha-Oliver Prolic
@prolic
You are free to copy and paste 2 files from the docs and you're already good to go.
George
@gdsmith
Just added a PR to bump the enqueue producer version prooph/psb-enqueue-producer#17
Sascha-Oliver Prolic
@prolic
prooph/common 4.5 release, now supporting PHP 8.0
thanks @gdsmith - will look into it soonish
5 replies
Fábio Carneiro
@fabiocarneiro
The event store client closes the connection when the object is destructed (Prooph\EventStoreClient\Internal\EventStoreNodeConnection->__destruct()). I am having some trouble figuring out why no events are being persisted with supposed to be valid configuration (tested with telnet from the container). I noticed the same behavior when replacing the host/port with random characters. I registered listeners to onConnected, onErrorOccurred, onAuthenticationFailed, onClosed and the only one that outputs to logs is onClosed, but the message is Connection close requested by client (__destruct()). I am also passing settings enableVerboseLogging on createFromEndPoint with no apparent difference. Any ideas?
Sascha-Oliver Prolic
@prolic
can you provide a test case similar to the demo scripts maybe?
just something that fails
Fábio Carneiro
@fabiocarneiro
will try, really odd. I checked the logs from eventstore side and nothing pops up. I can see my telnet connection there
Fábio Carneiro
@fabiocarneiro
exception <none> and connection === null?
Fábio Carneiro
@fabiocarneiro
ok I think I found my noob mistake... I was trying to upgrade an old app and was using the Async EventStore without the Amp Loop::run wrapping everything (There are no impl for Prooph\EventStore\EventStoreConnection). Then the Loop::defer that initializes the TcpPackageConnection was not running.
@prolic you have an issue here amphp/amp#235 asking for a Swoole adapter, but the link @codeliner posted is no more. Swoole would be a lot more friendly to my old code than Amp. Do you guys know the current state on this?
Sascha-Oliver Prolic
@prolic
Ask the Swoole authors where they moved it to.
anyone has time to update pdo event store as well?
Sascha-Oliver Prolic
@prolic
thanks and :beers: @fritz-gerneth
Fritz Gerneth
@fritz-gerneth
will do the pdo-store next :)
Sascha-Oliver Prolic
@prolic
thanks, appreciate it!
I have a baby coming any day and go-live on Wednesday, hence my limited amount of time available these days.
Sandro Keil
@sandrokeil
@prolic Congratulations! :tada: