Skip to content

Conversation

@MaxSchaefer
Copy link
Contributor

Which issues does this pull request close?

closes #873

@MaxSchaefer MaxSchaefer changed the title test proeprty UpdateNameEvent via protos test: define event sourcing events in proto Oct 21, 2024
}

func MessageToEventName(protoMessage proto.Message) string {
protoEventType := proto.GetExtension(protoMessage.ProtoReflect().Descriptor().Options(), pbEventsV1.E_EventType).(string)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if I want to work with a v2, v3 etc event?

a.RegisterEventListener(propertyEventsV1.PropertyFieldTypeDataSelectOptionsRemoved, a.onFieldTypeDataSelectOptionsRemoved)
a.RegisterEventListener(propertyEventsV1.PropertyArchived, a.onPropertyArchived)
a.RegisterEventListener(propertyEventsV1.PropertyRetrieved, a.onPropertyRetrieved)
a.RegisterEventListener(hwes.MessageToEventName(&pbTechnicalEventsV1.PropertyCreatedEvent{}), a.onPropertyCreated)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could move this into RegisterEventListener and get rid of a lot of code duplication + get better type guarantees

The go_package "property-svc" gets converted into "property_svc" for the generated Golang code.
If we can to import this proto, the generated Golang code imports "property-svc".
This inconsistency results in non-compiling Golang code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Can we define out event sourcing events in Protos?

3 participants