ptrdom commented on PR #194:
URL:
https://github.com/apache/pekko-persistence-r2dbc/pull/194#issuecomment-2676211679
The last two commits address shared config by breaking it up further. Now
configs of specific plugins contain only the settings they actually use - no
more inheritance of the whole `pekko.persistence.r2dbc` key.
Currently each config key fits one of these cases:
1) Key is used by only one plugin, so it is defined at the plugin level only.
Examples are `pekko.persistence.r2dbc.state.assert-single-writer` or
`pekko.persistence.r2dbc.query.deduplicate-capacity`.
2) Key is used by multiple plugins, but a clear hierarchy can be defined
between plugins, so the key is located at the parent plugin and a child plugin
uses parent's value through substitution.
Only journal and query plugins have keys like this - because query
plugin's purpose is to query data that is written by journal plugin, a clear
hierarchy can be defined. Keys are `pekko.persistence.r2dbc.journal.table` and
`pekko.persistence.r2dbc.journal.publish-events`.
3) Key is used by multiple plugins and there is no clear hierarchy between
the plugins and the key, so it is defined at under `pekko.persistence.r2dbc`,
where dependent plugins use the value through subsitution.
Most of the shared keys are under this category.
4) Key is used by multiple plugins, but is not defined under
`pekko.persistence.r2dbc`, instead being defined at each plugin.
`pekko.persistence.r2dbc.journal.plugin-dispatcher` and
`pekko.persistence.r2dbc.snapshot.plugin-dispatcher` are the only keys fitting
this case.
While the code has a more clear ideal implementation, the config changes can
be addressed in different ways, so I hope it is more clear now which approaches
are possible. For example, only the case 1 does not have arguably better
alternatives, where each case 2 and 3 key could be converted to case 4, or case
2 and 4 could be converted to case 3. Personally I feel that ideal solution is
either to keep only cases 1, 2 and 3, or 1, 2 and 4, so we would need to then
decide whether case 3 or case 4 is a better solution to same problem.
Could you share your thoughts @pjfanning?
--
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: notifications-unsubscr...@pekko.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org
For additional commands, e-mail: notifications-h...@pekko.apache.org
