kfaraz commented on issue #18008: URL: https://github.com/apache/druid/issues/18008#issuecomment-2939330608
That makes sense, @gianm . I agree that separate supervisors are much more easily maintainable than a composite supervisor. Although, there is one concern with making the `SupervisorId` a POJO rather than a plain String. All the GET APIs in `SupervisorResource` use the supervisor ID as a path parameter. So, I suppose we would need to expose new APIs for all of these operations. These new APIs could either be GETs which have two path params, one for datasource and one for supervisor name. Or POSTs and accept a `SupervisorId` in the payload. While the POST approach would be more extensible in the future, it would be weird to require POST calls for even simple get requests. As an alternative, how do you feel about using a UUID for the supervisor ID? Having a unique String supervisor ID allows for easy identification and has other conveniences like the GET APIs mentioned above. It also becomes completely independent of datasource name, and thus we are not bound in the future to have any relationship between a supervisor and datasource. So, we could potentially have supervisors in the future that are able to operate on multiple datasources. DB migration also becomes much simpler if we start using a UUID. We get to keep all the niceties of a unique supervisor ID. So `druid_supervisors` table doesn't need to change. And `druid_dataSource` table would just need a new column `supervisor_id` and any metadata entry would need to specify a value for either the `dataSource` column or `supervisor_id` column. If both are specified, we could just honor the value of the `supervisor_id` column since it is newer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
