Hi All, Polaris has been getting many new and interesting proposals lately. This is certainly good for the project.
On the other hand, we need to think about the stability and usability of the system as new features are introduced. Polaris is currently used in two modes: a) as a ready-made server for the default set of features (source or binary releases) and/or b) as a basis for custom downstream builds (from Maven artifacts). I'd like to propose the following general principles, which I hope will allow quick feature development without adding risks to either of the usage avenues. 1) Put code for new REST API services in isolated Gradle modules. 2) Wire those services into the runtime/server explicitly, behind feature flags where appropriate. 3) Do not add hard dependencies from runtime/service or polaris-core to REST API modules. 4) If a feature requires new Polaris entity types, add those core model changes in a dedicated PR so the entity and persistence contract can be reviewed on its own. New REST service modules can depend on those core entities, but existing core call paths should not depend on feature-specific entities. 5) Add new Persistence SPI(s) for non-entity storage (e.g. Scan/Commit Metrics). Keep new SPI classes in feature-specific Gradle modules. 6) Use isolated SQL schema definition files for each feature involving non-entity JDBC persistence. That is: separate .sql files for Metrics, Events, etc. Thoughts? Cheers, Dmitri.
