• Add projections via configuration
• How to reuse doctrine connection for PdoEventStore
• How to set up bus-bridge

Example bus bridge from prooph-do-sf

    prooph_event_store_bus_bridge.transaction_manager:
        class: Prooph\EventStoreBusBridge\TransactionManager
        tags:
          - { name: 'prooph_event_store.todo_store.plugin' }

    prooph_event_store_bus_bridge.todo_event_publisher:
        class: Prooph\EventStoreBusBridge\EventPublisher
        arguments: ['@prooph_service_bus.todo_event_bus']
        tags:
          - { name: 'prooph_event_store.todo_store.plugin' }

Hi there,

First of all, thanks for the work done!

It appears that the ProjectionManagerFactory hard code the types of allowed EventStore.
My problem was that I'm using a TransactionalActionEventEmitterEventStore, to be specific :)

So when I tried to configure a projection manager to use this store, if failed.
Indeed this store doesn't implement any of the providing PDO implementation of the event store.

You ask to open an issue before make any PR, so here I am.

The PR is ready anyway, I will push it to my fork onto a new branch with this issue number.

There is the link to the proposed solution

• bump version to event-store v7
• identify required changes in the set up logic
  • event store interface
  • new plugin registration
  • Aggregate and Snapshot namespaces moved to prooph/event-sourcing
  • persistent projections
• tbd

In PHP 8.2 some formats of callables were deprecated - one of those formats is ['self', 'myMethod'] which is exactly what is used here:

This raises a deprecation warning when running this code on PHP 8.2:

Deprecated: Use of "self" in callables is deprecated

In this excerpt I believe the prooph_event_store.projection_managers was supposed to contain the projection managers names, but currently they're prepended with prooph_event_store:

That parameter is only used on the ProjectionNamesCommand, so maybe it would make more sense to include only the names.

In production, bin/console event-store:projection:run command may be executed during a long time, we should be able to kill it after a given time in the same way Symfony Messenger consumers do to avoid PHP memory leaks. Then, using a process manager such as Supervisor to restart automatically worker

[program:eventstore-projection]
command=php /app/bin/console event-store:projection:run %(PROJECTION_NAME)s --time-limit=1800
autostart=true
autorestart=true
process_name=%(program_name)s_%(process_num)02d
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
redirect_stderr=true

[supervisord]
nodaemon=true

https://github.com/symfony/messenger/blob/master/Command/ConsumeMessagesCommand.php#L79

https://github.com/symfony/messenger/blob/master/Worker/StopWhenTimeLimitIsReachedWorker.php

Tests on master are currently broken. We have some open PRs so maybe this problem is fixed with one of them @prooph/symfony-team ?

your_snapshot_plugin:
       class: Prooph\Snapshotter\SnapshotPlugin
       factory: [Acme\EventStoreSnapshotPluginFactory, createPlugin]
       arguments: ['@prooph_service_bus.your_command_bus']
       tags:
             - { name: prooph_event_store.your_event_store.plugin }

From gitter: (@sandrokeil)
@itcraftsmanpl You can register the snapshotter as a plugin https://github.com/prooph/service-bus-symfony-bundle/blob/master/doc/getting_started.md

We should think about adding a recipe for the bundle to the recipes contrib repo

I propose to use a different naming for the repositories.

Given:

prooph_event_store:
    stores:
        foo_store:
            type: 'Prooph\EventStore\InMemoryEventStore'
            repositories:
                foo_collection:
                    repository_class: 'My\Own\Repository'
                    aggregate_type: 'My\Aggregate\Type'

will create a service named '@foo_collection', which is prone to errors (no namespace etc.). Upcoming symfony versions propose or use alread the FQCN as service-id, which makes it unique.

So a new configuration could look like:

prooph_event_store:
    stores:
        foo_store:
            type: 'Prooph\EventStore\InMemoryEventStore'
            repositories:
                My\Own\Repository:                
                    aggregate_type: 'My\Aggregate\Type'

There we enforce the FQCN for once as service-id, which is at the same time the repositoryclass.

I'm not sure if we should give it as "hint" in the docs, or enforcing it by omitting the 'repository_class' key, enforcing the use of FQCN.

What are your thoughts?

Using the latest projection configurations and commands, when a ReadModel is set on a projection and either event-store:projection:delete or event-store:projection:reset is called the delete and reset functions on the ReadModel are not also called.

I'm trying to enable SingleStreamStrategy to fix performance issues in projections (see proophsoftware/es-emergency-call#5 for details).

For now I'm unable to get it working. EventStore still makes one stream per aggregate instead of per aggregate type. Here is my current configuration:

services:
    Prooph\EventStore\Pdo\PostgresEventStore:
        arguments: ['@messageFactory', '@eventStoreConnection', '@stream_strategy']

    stream_strategy:
        class: Prooph\EventStore\Pdo\PersistenceStrategy\PostgresSingleStreamStrategy

In the documentation I found a link to this example to initialize the streams. This creates one more stream in the database but the EventStore is still creating new streams for every new aggregate. Also the example is confusing. Shouldn't I create one stream for each aggregate type instead of just one stream?

The "problem"

Today, there are two ways to define aggregate repositories using this bundle:

 prooph_event_store:
     stores:
         user_store:
             event_store: 'app.event_store.default'
             repositories:
                 user_collection:
                     repository_class: App\Infrastructure\User\Repository\EventStoreUserCollection

and

 prooph_event_store:
     stores:
         user_store:
             event_store: 'app.event_store.default'
             repositories:
                 App\Infrastructure\User\Repository\EventStoreUserCollection: ~

The later has the huge benefit of allowing autowiring to work out of the box.

As a matter of fact, the repositories key will be used as the service id and this is not obvious from a developer perspective.

The result will be that developers will get an error stating than the EventStoreUserCollection argument cannot be autowired when using the first form.

It is still doable though, through a service alias:

services:
    App\Infrastructure\User\Repository\EventStoreUserCollection: '@user_collection`

The suggestion

Remove the first form, aka force the repository service id to be a FQCN, thus making the autowiring always work.

The source

The issue appeared to me while reviewing this PR

Currently projections and plugins can be configured using tags and in the service bus bundle plugins and routing can be done using tags.

Just aggregate repositories cannot be configured using tags.

What's the recommended way to pass options to a projection? I'm looking to change the projector options.

I'm currently using the event-store:projection:run command but as far as I can tell, there's no way to modify the options without creating a new command with a lot of the code that's in AbstractProjectionCommand.

A few ideas:

1. Add an options property to AbstractProjectionCommand and then add my own command that uses the abstract overriding the options property. But this seems like near-copying code for no good reason (though less than copying the entire AbstractProjectionCommand).

2. Add options/arguments to the command to support all/most values that projectors support. The only issue I see here is that they'll get long and ugly unless we come up with shorten versions.

3. Add config options. The problem I see here is that you may want different options depending on the situation and we'd need to load them "everywhere" (or maybe just in the command). Though could be worth adding this along with 1 or 2.

I'm okay to attempt a first version of the change, but don't want assume which direction is preferred.

Hey there,

When I try to install the vendor through Composer to my Symfony 4.2 project:

composer require prooph/event-store-symfony-bundle

Then it throws an error due to the services are not defined through the Namespace\Class (or there aren't aliases for it):

This looks like a blocker for those users that are trying to use the bundle for the very first time.

Would be good if the services can define a valid Alias if you don't want to replace it everywhere.

Cheers,

Will provide autocompletion in some IDEs and is more consistent with prooph/service-bus-symfony-bundle.

Would be necessary at

• stores.<StoreName>.event_store
• stores.<StoreName>.repositories.<RepositoryId>.aggregate_translator
• projection_managers.<ManagerName>.event_store
• projection_managers.<ManagerName>.connection
• projection_managers.<ManagerName>.projections.<ProjectionName>.read_model
• projection_managers.<ManagerName>.projections.<ProjectionName>.projection

Came from:

• https://twitter.com/webdevilopers/status/1375519349725872128

Though this could be a general (PDO) Event Store issue I post it here first to get sure it is not a Symfony wiring problem.

We successfully register projections and an Upcaster as plugin:

prooph_event_store:
  stores:
    default:
      event_store: Prooph\EventStore\EventStore
      repositories:
        visit_collection:
          repository_class: Trexxon\Visit\Infrastructure\Persistence\PgsqlVisitEventStoreRepository
          aggregate_type: Trexxon\Visit\Domain\Model\Visit\Visit
          aggregate_translator: Prooph\EventSourcing\EventStoreIntegration\AggregateTranslator
          stream_name: 'visit_stream'

  projection_managers:
    default_projection_manager:
      event_store: Prooph\EventStore\EventStore
      connection: '@app.event_store.pdo_connection.pgsql'
      projections:
        visit_details:
          read_model: Trexxon\Visit\Infrastructure\Projection\MongoVisitDetailsReadModel
          projection: Trexxon\Visit\Infrastructure\Projection\MongoVisitDetailsProjection

services:
  Prooph\EventSourcing\EventStoreIntegration\AggregateTranslator: null

    Prooph\EventStore\EventStore: '@app.event_store.default'

    app.event_store.default:
        class: Prooph\EventStore\Pdo\PostgresEventStore
        arguments:
            - '@prooph_event_store.message_factory'
            - '@app.event_store.pdo_connection.pgsql'
            - '@app.event_store.pgsql.persistence_strategy'

    app.event_store.pdo_connection.pgsql:
        class: \PDO
        arguments:
            - '%env(PGSQL_DSN)%'
            - '%env(PGSQL_USER)%'
            - '%env(PGSQL_PASSWORD)%'

  Trexxon\Visit\Infrastructure\Projection\MongoVisitDetailsProjection: ~
  Trexxon\Visit\Infrastructure\Projection\MongoVisitDetailsReadModel:
    arguments: ['@doctrine_mongodb.odm.default_connection', '%env(resolve:MONGODB_DB)%']

  Prooph\EventStore\Plugin\UpcastingPlugin:
    arguments: ['@Trexxon\Common\Infrastructure\Prooph\EventStore\PersonalDataUpcaster']
    tags:
      - { name: 'prooph_event_store.default.plugin' }

  # Upcaster
  Trexxon\Common\Infrastructure\Prooph\EventStore\PersonalDataUpcaster:
    arguments: [ '@Trexxon\Common\Infrastructure\Prooph\EventStore\PgsqlPersonalDataStorage' ]

Upcasting works as expected when saving or getting aggregates from the AggregateRepository.
The used Event Store is an instance of Prooph\EventStore\TransactionalActionEventEmitterEventStore that holds a property named actionEventEmitter:

 Prooph\EventStore\TransactionalActionEventEmitterEventStore {#775 ▼
  #eventStore: Prooph\EventStore\Pdo\PostgresEventStore {#767 ▼
    -messageFactory: Prooph\Common\Messaging\FQCNMessageFactory {#768}
    -connection: PDO {#769 ▼
      inTransaction: false
      attributes: {▼
        CASE: NATURAL
        ERRMODE: SILENT
        PERSISTENT: false
        DRIVER_NAME: "pgsql"
        SERVER_INFO: "PID: 26359; Client Encoding: UTF8; Is Superuser: off; Session Authorization: trexxon; Date Style: ISO, DMY"
        ORACLE_NULLS: NATURAL
        CLIENT_VERSION: "12.4 (Ubuntu 12.4-1)"
        SERVER_VERSION: "12.6 (Ubuntu 12.6-0ubuntu0.20.10.1)"
        STATEMENT_CLASS: array:1 [▶]
        EMULATE_PREPARES: false
        CONNECTION_STATUS: "Connection OK; waiting to send."
        DEFAULT_FETCH_MODE: BOTH
      }
    }
    -persistenceStrategy: Prooph\EventStore\Pdo\PersistenceStrategy\PostgresSingleStreamStrategy {#770 ▶}
    -loadBatchSize: 10000
    -eventStreamsTable: "event_streams"
    -disableTransactionHandling: false
    -writeLockStrategy: Prooph\EventStore\Pdo\WriteLockStrategy\NoLockStrategy {#772}
  }
  #actionEventEmitter: Prooph\Common\Event\ProophActionEventEmitter {#776 ▼
    #events: array:15 [▼
      "create" => array:3 [▼
        "1.0" => array:1 [▶]
        "0.0" => array:1 [▶]
        "1000.0" => array:1 [▼
          0 => Prooph\Common\Event\DefaultListenerHandler {#830 ▼
            -listener: array:2 [▼
              0 => Prooph\EventStore\Metadata\MetadataEnricherPlugin {#826 ▶}
              1 => "onEventStoreCreateStream"
            ]
          }
        ]
      ]
      "appendTo" => array:3 [▶]
      "load" => array:2 [▼
        "1.0" => array:1 [▼
          0 => Prooph\Common\Event\DefaultListenerHandler {#782 ▶}
        ]
        "-1000.0" => array:1 [▼
          0 => Prooph\Common\Event\DefaultListenerHandler {#812 ▼
            -listener: Closure(ActionEvent $actionEvent): void {#811 ▼
              returnType: "void"
              class: "Prooph\EventStore\Plugin\UpcastingPlugin"
              this: Prooph\EventStore\Plugin\UpcastingPlugin {#807 …}
            }
          }
        ]
      ]
      "loadReverse" => array:2 [▶]
      "delete" => array:1 [▶]
      "hasStream" => array:1 [▶]
      "fetchStreamMetadata" => array:1 [▶]
      "updateStreamMetadata" => array:1 [▶]
      "fetchStreamNames" => array:1 [▶]
      "fetchStreamNamesRegex" => array:1 [▶]
      "fetchCategoryNames" => array:1 [▶]
      "fetchCategoryNamesRegex" => array:1 [▶]
      "beginTransaction" => array:1 [▶]
      "commit" => array:2 [▶]
      "rollback" => array:2 [▶]
    ]
    #availableEventNames: array:15 [▶]
  }
}

But when running projections the plugin is not used. The Event Store is an instance of Prooph\EventStore\Pdo\PostgresEventStore without the actionEventEmitter instead:

Prooph\EventStore\Pdo\Projection\PdoEventStoreReadModelProjector�]8;;file:///var/www/visitify/vendor/prooph/pdo-event-store/src/Projection/PdoEventStoreReadModelProjector.php#L37�\^�]8;;�\ {#201
  -eventStore: Prooph\EventStore\Pdo\PostgresEventStore�]8;;file:///var/www/visitify/vendor/prooph/pdo-event-store/src/PostgresEventStore.php#L40�\^�]8;;�\ {#340
    -messageFactory: Prooph\Common\Messaging\FQCNMessageFactory�]8;;file:///var/www/visitify/vendor/prooph/common/src/Messaging/FQCNMessageFactory.php#L20�\^�]8;;�\ {#315}
    -connection: PDO {#316
      inTransaction: false
      attributes: {
        CASE: NATURAL
        ERRMODE: SILENT
        PERSISTENT: false
        DRIVER_NAME: "pgsql"
        SERVER_INFO: "PID: 26659; Client Encoding: UTF8; Is Superuser: off; Session Authorization: trexxon; Date Style: ISO, DMY"
        ORACLE_NULLS: NATURAL
        CLIENT_VERSION: "12.4 (Ubuntu 12.4-1)"
        SERVER_VERSION: "12.6 (Ubuntu 12.6-0ubuntu0.20.10.1)"
        STATEMENT_CLASS: array:1 [
          0 => "PDOStatement"
        ]
        EMULATE_PREPARES: false
        CONNECTION_STATUS: "Connection OK; waiting to send."
        DEFAULT_FETCH_MODE: BOTH
      }
    }
    -persistenceStrategy: Prooph\EventStore\Pdo\PersistenceStrategy\PostgresSingleStreamStrategy�]8;;file:///var/www/visitify/vendor/prooph/pdo-event-store/src/PersistenceStrategy/PostgresSingleStreamStrategy.php#L23�\^�]8;;�\ {#317
      -messageConverter: Prooph\EventStore\Pdo\DefaultMessageConverter�]8;;file:///var/www/visitify/vendor/prooph/pdo-event-store/src/DefaultMessageConverter.php#L19�\^�]8;;�\ {#313}
    }
    -loadBatchSize: 10000
    -eventStreamsTable: "event_streams"
    -disableTransactionHandling: false
    -writeLockStrategy: Prooph\EventStore\Pdo\WriteLockStrategy\NoLockStrategy�]8;;file:///var/www/visitify/vendor/prooph/pdo-event-store/src/WriteLockStrategy/NoLockStrategy.php#L18�\^�]8;;�\ {#312}
  }
  -connection: PDO {#316}
  -name: "visit_details"
  -readModel: Trexxon\Visit\Infrastructure\Projection\MongoVisitDetailsReadModel�]8;;file:///var/www/visitify/src/Trexxon/Visit/Infrastructure/Projection/MongoVisitDetailsReadModel.php#L10�\^�]8;;�\ {#219
    -client: MongoDB\Client�]8;;file:///var/www/visitify/vendor/mongodb/mongodb/src/Client.php#L44�\^�]8;;�\ {#377
      -manager: MongoDB\Driver\Manager {#376}
      -readConcern: MongoDB\Driver\ReadConcern {#368}
      -readPreference: MongoDB\Driver\ReadPreference {#371
        +"mode": "primary"
      }
      -uri: "mongodb://localhost:27017"
      -typeMap: array:2 [
        "root" => "array"
        "document" => "array"
      ]
      -writeConcern: MongoDB\Driver\WriteConcern {#370}
      manager: MongoDB\Driver\Manager {#376}
      uri: "mongodb://localhost:27017"
      typeMap: array:2 [
        "root" => "array"
        "document" => "array"
      ]
      writeConcern: MongoDB\Driver\WriteConcern {#370}
    }
    -database: MongoDB\Database�]8;;file:///var/www/visitify/vendor/mongodb/mongodb/src/Database.php#L47�\^�]8;;�\ {#204
      -databaseName: "visitify_api"
      -manager: MongoDB\Driver\Manager {#376}
      -readConcern: MongoDB\Driver\ReadConcern {#194}
      -readPreference: MongoDB\Driver\ReadPreference {#195
        +"mode": "primary"
      }
      -typeMap: array:2 [
        "root" => "array"
        "document" => "array"
      ]
      -writeConcern: MongoDB\Driver\WriteConcern {#196}
      databaseName: "visitify_api"
      manager: MongoDB\Driver\Manager {#376}
      readConcern: MongoDB\Driver\ReadConcern {#194}
      readPreference: MongoDB\Driver\ReadPreference {#195}
      typeMap: array:2 [
        "root" => "array"
        "document" => "array"
      ]
      writeConcern: MongoDB\Driver\WriteConcern {#196}
    }
    -collection: MongoDB\Collection�]8;;file:///var/www/visitify/vendor/mongodb/mongodb/src/Collection.php#L67�\^�]8;;�\ {#197
      -collectionName: "visit_details"
      -databaseName: "visitify_api"
      -manager: MongoDB\Driver\Manager {#376}
      -readConcern: MongoDB\Driver\ReadConcern {#198}
      -readPreference: MongoDB\Driver\ReadPreference {#199
        +"mode": "primary"
      }
      -typeMap: array:2 [
        "root" => "array"
        "document" => "array"
      ]
      -writeConcern: MongoDB\Driver\WriteConcern {#200}
      collectionName: "visit_details"
      databaseName: "visitify_api"
      manager: MongoDB\Driver\Manager {#376}
      readConcern: MongoDB\Driver\ReadConcern {#198}
      readPreference: MongoDB\Driver\ReadPreference {#199}
      typeMap: array:2 [
        "root" => "array"
        "document" => "array"
      ]
      writeConcern: MongoDB\Driver\WriteConcern {#200}
    }
    -stack: []
  }
  -eventStreamsTable: "event_streams"
  -projectionsTable: "projections"
  -streamPositions: []
  -persistBlockSize: 1000
  -state: []
  -status: Prooph\EventStore\Projection\ProjectionStatus�]8;;file:///var/www/visitify/vendor/prooph/event-store/src/Projection/ProjectionStatus.php#L26�\^�]8;;�\ {#172
    -value: "idle"
    -ordinal: null
  }
  -initCallback: null
  -handler: null
  -handlers: []
  -isStopped: false
  -currentStreamName: null
  -lockTimeoutMs: 1000
  -eventCounter: 0
  -sleep: 100000
  -triggerPcntlSignalDispatch: false
  -updateLockThreshold: 0
  -gapDetection: null
  -query: null
  -vendor: "pgsql"
  -lastLockUpdate: null
  -metadataMatcher: null
}

There is a handlers property but it is empty.

Should the used Event Store instances not be the same?

Refs:

• #55 @camilledejoye
• #64 @stefangr
• prooph/event-store#254 @mrook
• prooph/event-store#255
• #10 by @lunetics

In some environments I get the following error:

Relying on its factory's return-type to define the class of service "prooph_event_store.projection_manager.xxx_projection_manager" is deprecated since Symfony 3.3 and won't work in 4.0. Set the "class" attribute to "Prooph\EventStore\Projection\ProjectionManager" on the service definition instead: 1x

I assume the best solution is to add the class parameter when creating the service inside \Prooph\Bundle\EventStore\DependencyInjection\ProophEventStoreExtension::loadProjectionManagers

I just encountered an issue where one of my projection was in an invalid state after being interrupted during previous run. The state of the projection was not saved to the database correctly

I believe the projection commands in this bundle could and should catch interruption signals like Ctrl+C and shutdown correctly when it happens using pcntl_signal function. Something like this (by @prolic):

pcntl_signal(SIGINT, function () use ($projection) {
    $projection->stop();
});

I'm not using the projection commands from this bundle at the moment but I'm going to refactor my project to use them soon. I might take a look into this then too.

Any tips what I should be aware of? I never tried working with pcntl_signal function until now.

Hi, I would like to know if in your roadmap is the upgrade to symfony 7.

Thanks,

It is still not possible to use ramsey uuid 3.x with symfony.

Problem 1
    - Installation request for prooph/event-store-symfony-bundle ^0.2.2 -> satisfiable by prooph/event-store-symfony-bundle[v0.2.2].
    - Conclusion: remove ramsey/uuid 3.7.1
    - Conclusion: don't install ramsey/uuid 3.7.1
    - prooph/event-store-symfony-bundle v0.2.2 requires prooph/event-store ^6.3 -> satisfiable by prooph/event-store[6.x-dev, v6.3.0, v6.4.0, v6.5.0, v6.5.1, v6.6.0].
    - prooph/event-store 6.x-dev requires prooph/common ~3.7 -> satisfiable by prooph/common[3.x-dev, v3.7, v3.7.1].
    - prooph/event-store v6.3.0 requires prooph/common ~3.7 -> satisfiable by prooph/common[3.x-dev, v3.7, v3.7.1].
    - prooph/event-store v6.4.0 requires prooph/common ~3.7 -> satisfiable by prooph/common[3.x-dev, v3.7, v3.7.1].
    - prooph/event-store v6.5.0 requires prooph/common ~3.7 -> satisfiable by prooph/common[3.x-dev, v3.7, v3.7.1].
    - prooph/event-store v6.5.1 requires prooph/common ~3.7 -> satisfiable by prooph/common[3.x-dev, v3.7, v3.7.1].
    - prooph/event-store v6.6.0 requires prooph/common ~3.7 -> satisfiable by prooph/common[3.x-dev, v3.7, v3.7.1].
    - prooph/common 3.x-dev requires ramsey/uuid ~2.8 -> satisfiable by ramsey/uuid[2.8.0, 2.8.1, 2.8.2, 2.8.3, 2.8.4, 2.9.0, 2.x-dev].
    - prooph/common v3.7 requires ramsey/uuid ~2.8 -> satisfiable by ramsey/uuid[2.8.0, 2.8.1, 2.8.2, 2.8.3, 2.8.4, 2.9.0, 2.x-dev].
    - prooph/common v3.7.1 requires ramsey/uuid ~2.8 -> satisfiable by ramsey/uuid[2.8.0, 2.8.1, 2.8.2, 2.8.3, 2.8.4, 2.9.0, 2.x-dev].
    - Can only install one of: ramsey/uuid[2.8.0, 3.7.1].
    - Can only install one of: ramsey/uuid[2.8.1, 3.7.1].
    - Can only install one of: ramsey/uuid[2.8.2, 3.7.1].
    - Can only install one of: ramsey/uuid[2.8.3, 3.7.1].
    - Can only install one of: ramsey/uuid[2.8.4, 3.7.1].
    - Can only install one of: ramsey/uuid[2.9.0, 3.7.1].
    - Can only install one of: ramsey/uuid[2.x-dev, 3.7.1].
    - Installation request for ramsey/uuid (locked at 3.7.1) -> satisfiable by ramsey/uuid[3.7.1].

https://github.com/prooph/event-store-symfony-bundle/security/dependabot/composer.json/symfony%2Fhttp-kernel/open

@webdevilopers @unixslayer I let you handle this

On Symfony4 and event-store-symfony-bundle 0.4, it's not possible to define your projections as a service, and then run them.

Example service definition:

    Argus\Domain\User\Projection\CredentialsProjection:
        public: true
        class: Argus\Domain\User\Projection\CredentialsProjection
        arguments: ['@fos_user.util.user_manipulator']
        tags:
            - { name: 'prooph_event_store.projection', projection_name: 'user_credentials_projection', projection_manager: 'argus_projection_manager', read_model: 'Argus\Domain\User\Projection\CredentialsReadModel' }

Projections are expected to be added to the event store via the config. Example:

    projection_managers:
        argus_projection_manager:
            event_store: Prooph\EventStore\Pdo\MySqlEventStore # event store
            connection: 'doctrine.pdo.connection'
            projections:
                user_credentials_projection:
                    projection: Argus\Domain\User\Projection\CredentialsProjection

This configuration causes the ProophEventStoreExtension class to create new services in the container with id prooph_event_store.projection.<projection name> and given projection class.

Since Symfony4, multiple service definitions for the same class are not allowed. So the existing service definition cancels out the creation of the prooph_event_store.projection.<projeciton name>one, which results in an empty Locator service that is being used by the AbstractProjectionCommand.

Current workaround is to:

• Manually create an alias prooph_event_store.projection.<projection name> for the service which is already defined for the projection class
• Add the projection to the configuration, as is expected by this bundle

The symfony command event-store:projection:names is broken.
it now returns

[Symfony\Component\Console\Exception\InvalidArgumentException]
The "projection-name" argument does not exist.

It is because it extends the AbstractProjectionCommand which tries to get the projection name of the argument. But that is not used in that command.

Since prooph/event-sourcing is abandoned, dependency should be dropped. This bundle do not need to support EventStore configuration for ProjectionManager to be configured properly, it only require to pass valid service that implements \Prooph\EventStore\EventStore interface.

Dropping this dependency will also be a good starting point to be able to integrate with EventStore:v8 much easier in the future.

We also have a blueprint for writing own ES.

When providing a limit, it is not used:

$php bin/console event-store:projection:names -l 100

Returns the default amount of 20 projection names.

When I look into the code, the provided limit is simply not passed to the method for fetching the projection names:

            } else {
                $projectionNames = $projectionManager->$method($filter); // <-- $limit & $offset
            }

Tried a short fix: #20
But this breaks the command entirely, so we need to find a better way.

Currently playing around with the Symfony DataCollector. To get "real" debugging, would it be an option to extend the event-store with a logger? (could be nulllogger by default, so no overhead)

As discussed on Gitter: At the moment the event-store implementation to be used needs to be configured by the users as a "Userland Service"

Better:
Extend Configuration class with the needed parameters for a \PDO connection and automatically instantiate the concrete implementation in the Dependency Injection Extension.

I can't autowire repositories – is this an issue or deliberate action?
Here is my event store configuration:

prooph_event_store:
    stores:
        user_store:
            event_store: 'prooph_event_store.pdo_mysql_event_store'
            repositories:
                App\Infrastructure\User\Repository\EventStoreUserRepository:
                    aggregate_type: App\Domain\User\Model\User
                    aggregate_translator: 'prooph_event_sourcing.aggregate_translator'

And here is the error:

Cannot autowire service "App\Infrastructure\User\Repository\EventStoreUserRepository": argument "$aggregateType" of method "Prooph\EventSourcing\Aggregate\AggregateRepository::__construct()" references class "Prooph\EventSourcing\Aggregate\AggregateType" but no such service exists.

http://docs.getprooph.org/event-store/event_store_plugins.html

I try to to register a metadata enricher for authenticated events:

services:
  app.metadata_enricher:
    class: "App\\EventStore\\MetadataEnricher\\AuthenticatedEventMetadataEnricher"
    autowire: true
    autoconfigure: true

  app.metadata_enricher_plugin:
    class: "Prooph\\EventStore\\Metadata\\MetadataEnricherPlugin"
    arguments:
      - '@app.metadata_enricher'
    calls:
      - method: attachToEventStore
        arguments:
          - '@app.event_store.default'

But event-store configuration does not allow plugin registering such as service-bus does.

Could someone please advice if it is possible to use the dev version of event-store-symfony-bundle already?

I can't figure out how to create PostgresEventStore with transactions to use in event_store as before.

Since event-store-doctrine-adapter is deprecated, it isn't possible to create event store using DoctrineEventStoreAdapter I suppose we should use pdo-event-store somehow now.

Currently the bundle requires the symfony dependencies in version ~2.8 || ~3.0.
Within the DI-Extension the Symfony\Component\DependencyInjection\DefinitionDecorator is used which is deprecated since v3.3 and will be removed in v4.0.

Because the service-bus-symfony-bundle already requires at least v3.3, I would suggest to raise the version of the symfony dependencies to ~3.3 and get rid of the DefinitionDecorator.

See prooph/service-bus-symfony-bundle#32