Repository navigation
DependentResource support for event sources where multiple resources of same type are handled for single primary #1175
Description
In the following PR: #1169 we made sure that every resource event source can handle multiple secondary resources for a primary. A dependent resource however now represents a single resource on cluster. So in order to share a event source between more resource that are (the same type and) related to a single primary resources, we would need to have a discriminator function. So if a dependent resource receives from Set<R> getSecondaryResources() multiple resources this discriminator will select which one to handle from the set.
This is a relative simple but useful way to support this case.
Reacted by Konstantin Gribov, BramMeerten and Matthias Grawinkel
Activity
[-]`DependentResource` support for event sources where multiple resources are handled for single primary[/-][+]`DependentResource` support for event sources where multiple resources for same type are handled for single primary[/+][-]`DependentResource` support for event sources where multiple resources for same type are handled for single primary[/-][+]`DependentResource` support for event sources where multiple resources of same type are handled for single primary[/+]grossws commentedon Oct 21, 2022
FtR: As a workaround for 3.2.x one could try to use distinct labels for different managed resources of the same type plus explicit
@Dependent(name = "some-name", type = SomeResource.class)and then use eithercontext.getSecondaryResources(Deployment.class)orcontext.getSecondaryResource(Deployment.class, "some-name")(but it could be deprecated in #1240).Not sure if it will lead for other issues though, so it's just a possible approach. I hope @csviri would correct me if it's a wrong way to do it in 3.2.x and if there's better approach.
As example of such approach there's my reproducer project for another issue.
csviri commentedon Oct 24, 2022
Hi @grossws, in v4.1 (will are getting it released shortly) there will be an explicit support for that. But there is no other approach now in 3.2.