Hello,
I’d like to gauge the community interest in making JDBCDataStore be more extensible, mainly by making it non-final (and possibly exposing some private methods or additional integration hooks). The custom dialect approach provides a lot of flexibility, but at times I’ve found myself wanting more (most recently, around applying row-level security policies). Would anyone be opposed if I opened a PR with that change?
Thanks,
Emilio Lahr-Vivaz
The JDBCDataStore was made final after a terrible experience with the first generation of GeoTools datastores turning into an unmaintainable mess (as opposed to the current maintainable mess?).
I would prefer if we add more hooks, the really big “dialect” hook is usually sufficient.
I understand that low-level integration for security can be a challenge; would it be possible to inject a JDBCSecurityCheck object of some sort?
Makes sense - people would be open to additional dialect hooks, then? (In this particular case I was trying to add a column for row-level visibility checks, but was hoping to not expose it to the end user - but there are no hooks around creating feature types based on the table columns, nor on setting additional values on insert, so those are probably the places I’d want to expand first.)
Thanks,
Yes very much open to adding to the existing dialect, or if appropriate making an additional security focused one.
You may wish to look at what geofence does (as it already covers some of those row / column restrictions).