Question for the community: What would you prefer?

A

Connect the https://github.com/prooph/event-store-client to the "original" event-store (https://eventstore.org/)

B

Connect the https://github.com/prooph/event-store-client to a newly written event-store server implementation written in PHP

C

Use a simple library on top of a PDO connection (like event-store v7), no server implementation.

You can vote multiple times, just leave a :+1: on mulitple answers.

Pros / Cons of the different solutions:

A

Pro: The server from https://eventstore.org/ is the best solution available, has the most features and awesome performance.

Con: Most PHP devs know a PHP / MySQL combo and would have to learn how to setup the event-store as well. Sometimes you can't make decisions on the stack used (but you can install any PHP lib you want to).

B

Pro: Way more features are possible to implement compares to a simple library on top of a PDO connection. Communication is with client / server, not directly via PDO connection.

Con: Not all features from https://eventstore.org/ are possible to implement with PHP (but most). Communication is with client / server, not directly via PDO connection (I think some may see this as a con, so I list here again).

C

Pro: No additional server setup needed, not https://eventstore.org/ and not a newly written server implementation in PHP.

Con: The smallest feature set of all solutions. Performance of projections is not as good.

• [x] added projection manager
• [x] removed projection options class
• [x] projection options constants
• [x] added methods to fetch projection state, status and stream positions
• [x] added common event store test for all implementations
• [x] added common transactional event store test trait for all implementations
• [x] added common projection manager test for all implementations
• [x] added common event store projection test for all implementations
• [x] added common event store query test for all implementations
• [x] added common event store read model projection test for all implementations
• [x] updated all fetch*-methods
• [x] provided more tests
• [x] some bug fixes

supersedes https://github.com/prooph/event-store/pull/266

resolves https://github.com/prooph/event-store/issues/265

resolves https://github.com/prooph/event-store/issues/257

/cc @oqq

Currently it delegates the projection creation to the used event store implementation. This is a problem, as the wrapped event store is then not used in the projection itself, and you cannot attach listeners to it during projection's emit and linkTo.

$eventStore->createProjection($eventStore) would solve the issue (adding event store as optional parameter, which will only be set by action event emitter event store) - but this looks weird and might lead to some people injecting a complete different event store instance, which would be cleary wrong.

Ideas?

@codeliner @oqq @bweston92

Implementation for:

RFC load max events and direction https://github.com/prooph/event-store/issues/198

RFC Remove Adapter::replay method https://github.com/prooph/event-store/issues/190

The current base implementation of ProjectionOptions has some mandatory values with defaults, which would not be used in every projection class. There is also an inheritance in PdoEventStoreProjection to add more options. To provide one value other than the defaults, I have to investigate the default values in the class and add they by myself in the constructor, otherwise the object could not be build.

I guess this would escalate.

My proposal is to make this DTO more abstract, so it can be used in every current and future implementation of projection and here factories.

Default values required by the factories should be defined by the factory and not in an abstract DTO. Also, every projection should know which options are mandatory.

Here is an example implementation to be more clear what I am talking about: https://gist.github.com/oqq/c709eae6d993b49d888d15703a466f30

This would be a bc break and should not implemented in an already beta version. But I guess there is not an implementation for projections out there other than from us.

What do you think about that? @prolic @codeliner

A user-interface for inspection of the event-store would be a great new feature. This can be done in a separate package. An event-store HTTP API would be needed, see: https://github.com/prooph/event-store/issues/194

The current interface is:

public function load(StreamName $streamName, int $minVersion = null): Stream

I want to change to:

public function load(StreamName $streamName, int $minVersion = null, int $maxVersion = null, bool $forward = true): Stream

to allow loading events in a given range only (useful for http api f.e., see: https://github.com/prooph/event-store/issues/194) and additionally you can load the events in reverse order.

Similar to this loadEvents needs to be updated, too.

move constants from projection manager to projector interfaces

resolves https://github.com/prooph/event-store/issues/273

Please check the new naming and check for consistency where it's still called projection, and where it's now called projector, f.e.

ProjectionManager::createProjection(): Projector

/cc @basz @oqq @bweston92

If accepted, we need to update pdo-event-store before merging, then we are ready for next beta I guess

• ~~Travis is currently missing the PHP 8 option ( https://travis-ci.community/t/php-8-0-missing/10132/17 ) but should be available next week~~
• This is mostly to see if/what needs to change to PHP8 support

Changes:

• [x] Updated the README badges to link to the correct branch for this version
• [x] Use ProphesizeTrait, prophesize integration has been moved into its own package phpspec/prophecy-phpunit
• [x] Replaced calls to assertInternalType() with new assertions ( old ones have been removed )
• [x] assertRegExp is deprecated and replaced
• [x] Annotated a few tests with @medium that were running longer than 1 second and thus being stopped
• [x] Update travis
• [x] Fix at deprecation warnings in phpunit
• [x] Update Doc-Header for 2021

Solves incompatibility of InMemoryEventStore and PdoEventStore as explained in this SO question: https://stackoverflow.com/questions/46769347/how-to-solve-incompatibility-of-inmemoryeventstore-and-pdoeventstore-in-prooph/46806028#46806028

We can get rid of the autoincrement requirement for an event store if we use Universally Unique Lexicographically Sortable Identifier. This would be a huge improvement.

The assumption why autoincrement no is needed is:

1. Sort events ASC or DESC
2. Get events prior or after specific number

Try it out with php-ulid.

        $docs = [];

        for ($i=0; $i<100; $i++) {
            $docs[] = [
                'position' => $i,
                'ulid' => (string)Ulid::generate(true),
            ];
        }

It works in ArangoDB for instance.

FOR u IN transactionCol
  FILTER u.ulid <= "01d4dn314dz3pp0n423pfggjv2"
  SORT u.ulid ASC
  RETURN u

Updates the requirements on vimeo/psalm to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I tried to search for Prooph Add Metadata and got this page as 1st result: http://getprooph.org/docs/html/event-store/event_store.html

I think the right/updated documentation in different host: http://docs.getprooph.org/event-store/event_store_plugins.html#3-3-4

I think it's important to have results in google to redirect to right documentation :)

Thanks