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
Xavi Montero
@xmontero
I guess "State" means the aggregate cached state (Ie: the "state that the projection is calculating itself" for example in an adder of sales by month, the "list of months with the accumulated up to the last processed event"). Question => Is that "aggregate state" what we mean by being able to "Fetch the projection state"?
And "Status" I guess it means it it's running, stopped, etc... Questions => Is this correct? What is the list of possible statuses?
thanks to @danieleartico
@xmontero Can't remember those status from the top of my head, but you should be able to find them in code
Fritz Gerneth
@fritz-gerneth
@xmontero stream position: last one, state: correct, you can carry persistent projection state (though I'd recommend to avoid it), status: correct, it is used both to indicate the current status and control the status (e.g. a CLI script can set the status, the projection in another process reads it and stops)
Dariusz Gafka
@dgafka

Hello,

I would like to ask, about difference in implementation between PdoEventStoreProjector (https://github.com/prooph/pdo-event-store/blob/master/src/Projection/PdoEventStoreProjector.php#L332) and PdoEventStoreReadModelProjector (https://github.com/prooph/pdo-event-store/blob/master/src/Projection/PdoEventStoreReadModelProjector.php).

Is there a reason, why ReadModelProjector does not provide emit and linkTo methods?

Sascha-Oliver Prolic
@prolic
Yes, it is meant to create read models, f.e. in some rdbms, elastic search,...
The other projects event streams to event streams
lunetics @lunetics cheers around ... back for a new CQRS project :D
Matthias Breddin
@lunetics
inspect io looks sick... can't wait to play around with it
Still need to get an overview, all the tools look a bit fragmented
Alexander Miertsch
@codeliner

hey @lunetics welcome back!
Regarding fragmentation of the tools. It is related to responsibilities:
prooph components (mainly event store v7 and v8 at the moment) is maintained by prooph OS core contributors
InspectIO, Cody (Code Generator) and everything related to Event Engine is developed and maintained by my company prooph software GmbH

So I have a double role: CEO of prooph software and core contributor of prooph OS
I'm willing to support a revival of prooph event-sourcing, if it would be based on InspectIO + Cody. Here is the open discussion: prooph/event-sourcing#90

Anyway, you can play around with InspectIO any time. The coding bot tutorial contains a link to a free version of it. We're working hard on documenting the advanced use cases like complete Value Object code generation or adding new methods to existing aggregates with a PHP AST based code generator. @sandrokeil can answer questions about it. He worked hard on it.

Matthias Breddin
@lunetics
InspectIO looks really sick
gonna play around with that sometime
What I can tell so far: Handling stuff for a 20k+ visitor open air festival... including ticket sales and lifecycles (till ticket will be validated in-field), visitor management (ticket, documents, e.g. if applicate uplod vaccination pass), tracking in times of covid... backoffice management (artists, press, crewhandling) etc
so quite a complex domain
will replace a mess of unsynchronized excel lists and a lot of ping-pong emails and phone calls
just found the tutorial for event-engine today, also looks really nice... i guess you need to get used to it somewhat
but i like the multi document store approach
Matthias Breddin
@lunetics
but from what i understood, event-engine works with event-store, correct? Where can one place the event store http client?
Alexander Miertsch
@codeliner
that's only a planned feature. At the moment event-engine only supports prooph/event-store v7 with Postgres
Event Engine has its own simplified event store interface so that event store http client could be used, but then the multi-document-store could not be used ...
If you want to use event store http client, Event Engine is not the best choice.
Alexander Miertsch
@codeliner

i guess you need to get used to it somewhat

Yeah, absolutely. It is highly opinionated, but also fully customizable thanks to Event Engine Flavours. I can only say that once you get used to it, Event Engine makes a lot of fun and saves huge amount of time. But it is our company framework so we designed it to fit our needs best, which are:

  • fast MVP development
  • provide good balance between eventual consistency, coupling and performance
  • easy way to switch from strong consistency to eventual consistency on a case by case basis (iterative design, incremental improvements)
  • out-of-the-box documentation (Event Engine Descriptions, InspectIO Code Gen, ...)
Alexander Miertsch
@codeliner

For one of our clients we integrated parts from Event Engine in their internal company framework. Parts are:

  • Multi-Model-Store behind aggregate repositories
  • Splitting of Aggregates into: behavior and immutable state
  • Immutable value objects with event-engine/data
    +
  • prooph es v7 used as Event Store per context and also as a shared event store to exchange events between different contexts
  • prooph projections
  • prooph/common messages

Currently integrating InspectIO Cody into their stack. They are using InspectIO since a year now (> 70 people). It definitely changed the way how teams coordinate their work and collaborate x-team. really powerful toolbox if you want to go fully EDA

Matthias Breddin
@lunetics
yep.. IF i understand correctly from the tutorial, you split up the aggregate behaviour AND the state
Never thought of this before
Haven't really diggen into the flavours.
What's your experience on the always evolving model / aggregate
especially upgrading / extending events with event-engine (which is imho not just a pure event-store responsibility)
Zacharias Luiten
@netiul
I wonder about that too.
Alexander Miertsch
@codeliner

@lunetics @netiul
so far we did not run into trouble. Event Engine suggests to use immutable state for messages, as well as aggregate state and of course all value objects.
This combined with JSON Schema gives you strict types at runtime. If your structure evolves (be it an event or aggregate), you can pick one of the common strategies to get the change into your system:
1) Add nullable properties to existing structure: https://event-engine.io/api/immutable_state.html#3-4-5-2
2) Initialize new properties with a default: https://event-engine.io/api/immutable_state.html#3-4-5-4
3) Introduce a new event or use schema versioning (version in event name for example)
4) perform a stream-to-stream projection and change events from old to new
5) Rebuild aggregate state according to new structure
6) Introduce new aggregate and support old one only as long as existing instances are "closed"
7) Use upcasting
...

I think meanwhile we used each of those strategies at some point. In InspectIO for example we had to refactor a couple of aggregates and event flows because we introduced "Organizations" as a new structural layer. We had to refactor Team-Aggregate, Board-Aggregate, the way how one can share a board, invite members to a team and so on. Organization admins can now access all boards and teams of an organization, can invite guests, turn them into members, ....
That change was really tricky. We worked on it couple of weeks, started with Big Picture Event Storming and iterated on the solution with multiple design level stormings and implementation sprints. At the end I just deployed the new feature and activated it for our pro users without any issue. Most of them did not even notice that something had changed ....

Alexander Miertsch
@codeliner
For a logistics platform we used stream-to-stream projections multiple times for example to extend tracking events or split contexts. We built a MVP with Event Engine and then started to split the system into smaller services.
Alexander Miertsch
@codeliner

Regarding aggregates:

you split up the aggregate behaviour AND the state

Exactly. Even the OOP Flavour of Event Engine uses this approach, with the difference that state is part of the aggregate, but is THE ONLY property and THE ONLY mutable part of the aggregate. This design is inspired by FP and for example Vaughn Vernon suggests a similar design in his vlingo/platform
It underlines the functional nature of event sourcing and moves you further away from traditional Entity-ORM style.
Especially in combination with the Multi-Model-Store you can safely reuse aggregate state for queries, because it is immutable. You can pass it around and use it insight other aggregates because immutability ensures that you cannot change that state outside of aggregate behavior and without recording an event.

Alexander Miertsch
@codeliner
pdo-event-strore supports PHP8 now :tada: https://github.com/prooph/pdo-event-store/releases/tag/v1.13.0
thank you @fritz-gerneth :beers:
Fritz Gerneth
@fritz-gerneth
one less blocker to php8 adoption :beers:
Sandro Keil
@sandrokeil
:tada: :beer: What do you think about introducing CI Automation for prooph like described here https://mwop.net/blog/2021-03-12-laminas-ci.html ? I use automatic releases for https://github.com/open-code-modeling and it's awesome. I'm also planning to add the other two GitHub actions too.
2 replies
Sascha-Oliver Prolic
@prolic
for those interested: https://github.com/prooph/event-sourcing/releases/tag/v5.7.0 <- now with PHP 8.0 support
thanks to @fritz-gerneth
Fritz Gerneth
@fritz-gerneth
cheers @prolic - onward to the snapshotters :)
Sascha-Oliver Prolic
@prolic
@fritz-gerneth prooph/snapshotter#36 - is still WIP, right?
Fritz Gerneth
@fritz-gerneth
yes, it has a dependency on the event-sourcing
Sascha-Oliver Prolic
@prolic
if I missed any pull requests, just ping me again please. I try to catch up with all those unanswered emails and github issues.
Fritz Gerneth
@fritz-gerneth
no worries, nothing urgent from my side, just preping / using idle time :)
Sascha-Oliver Prolic
@prolic
Two months ago my forth child was born and I had a very stressful go-live with a project - I am way behind my normal schedule and need to work through a lot of things and catch up again.
Fritz Gerneth
@fritz-gerneth
figured (you wrote that a while ago) :)
still hope to write event-store v8 this year.. but things are moving so slow :(
(v8 for mysql that is)
Sascha-Oliver Prolic
@prolic
I hope to finally finish the docs and release v8 stable
Martijn van Maasakkers
@mvmaasakkers
Goodday! Does anyone know of an example of the pdo event store with sqlite?
Alexander Miertsch
@codeliner
Hi @mvmaasakkers, pdo event store does not support sqlite, only Postgres, MySql, MariaDB
we have an InMemoryEventStore if you need something for testing