Open fdelbrayelle opened 4 years ago
Is it in accordance with your use cases @pascalgrimaud?
yes, it's nice it could be split into several part, like create, update and delete, and for each case, think about how to implement it.
The hardest would be deleted, as I think we should forbid this, and implement a logical delete, rather than a physical one. It should be discussed
I think we should follow what it's done on the main generator for entities deletion. In my opinion, we just have to manage an event on CRUD operations, not operations themselves. What do you think?
Overview of the feature request
When CRUDing on entities, it should send events in topics for given entities.
Maybe propose this by a prompt option?
This could be linked with #4 where consumer/producer would be created by hook when using
jhipster entity Foo
.An event type could be send as a key when producing a message for instance:
An enum could be generated with the different operations values (create, update, delete).
Motivation for or Use Case
Allowing the application to be event-driven.
Use case:
Foo
entity, create aFooProducer
.Foo
entity, create aFooConsumer
.Foo
in the application.queuing.application_name.foo
topic throughFooProducer
in JH1.queuing.application_name.foo
topic byFooConsumer
in JH2.:warning: On JH2 the entity could not be deserialized correctly because the entity doesn't have the same package on JH1 and JH2. Make a test with current deserialization mode or see #63 for deserialization alternatives (to be priorized ?).
Add support for akhq to be launched on multiple apps.
Related issues or PR
4