Configuration option for database table name

[benr77]

Currently the DB table name "event" is hard-coded in to the Doctrine mapping.

It would be good to allow this value to be configured via the bundle configuration.

[soulcodex]

This feature could be great for the package, I forked the package and covered at 100% with unit test, maybe could be interesting merge the package. On the way i encountered certain bugs when builtin symfony commands are running.

[soulcodex]

If you accept the PR let me know :heart:

[benr77]

Hello. I'm definitely up for some PRs. Would you be able to create a PR which only includes the unit tests? We should get that merged before anything else. Thanks

[soulcodex]

Sure :heart:

It is possible change the event bus to send the events to queue and attend them later?

[benr77]

That is exactly what this bundle does. It persists the events to a database table, and then publishes them later.

The bus to which it then publishes to is configurable too - see https://github.com/headsnet/domain-events-bundle#messenger-component.

You can also easily set a future publishing date on an event to defer publishing.

[soulcodex]

Yes but all occur at runtime not in background and if the events publish comsuption fails the request fail :cry: and maybe the executed event isnt related with the request.

[benr77]

Only the publishing to the message bus occurs in the TERMINATE stage of the request. You should then pick them up to process ASYNC using the Symfony Messenger consume command.

Yes but all occur at runtime not in background and if the events publish comsuption fails the request fail cry and maybe the executed event isnt related with the request.

This is correct if you don't consume the events asynchronously.

[soulcodex]

So maybe the correct approach for this is identify the message with a interface for example SynchronousDomainEventInterface for synchronous domain event bus and AsynchronousDomainEventInterface to delegate the message to asynchronous infrastructure (RabbitMQ, Amazon SQS, Kafka, etc).

[benr77]

Well yes, that would be a good way to go. But that is left for the client application to implement depending on requirements. This bundle does not need to be so prescriptive.

We could add the interfaces to the bundle, to save them being created in each client application, but again this means the client application would have to take our naming convention if they used them, and for the sake of a couple of marker interfaces I don't think this is worth doing in the bundle.

I just have this in my messenger.yaml configuration:

framework:
    messenger:
        routing:
            # Publish all domain events asynchronously
            'Headsnet\DomainEventsBundle\Domain\Model\DomainEvent': async

This could be a useful addition to the documentation.

[soulcodex]

Yes thats maybe is just a personal point of view about one possible way to implement domain events classification based on when you want consume the event inmediatly or later using queues. I already forked the package let me add the test suite to do the PR.

Have a nice week buddy