Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.2.0-incubating
-
Component/s: None
-
Labels:
Description
For users who want more fine-grained control over their Avatica server instance, we should open up the class-level protections on relevant classes. That way folks can instantiate/subclass as they require.
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
These changes increase the surface area of the API. People will presume that these are public APIs and complain if they change.
Can we introduce a maturity model?
They do indeed become public APIs.
Hadoop and HBase have annotations for InterfaceAudience and InterfaceStability annotations. Would you like to see something similar for Calcite?
Yes, that would be awesome. Are those annotations packaged in such a way that we could use them? (Zero-dependency jar, ideally not retained at runtime, so we'd only need the jar at compile time.) Otherwise we could make our own in org.apache.calcite.avatica.util, alongside @PackageMarker.
Hadoop's annotations package caries a dependency on jdiff, and appears to include some custom docklets for excluding sources from a jdiff report based on annotation. HBase's annotation jar has no dependencies.
Probably Calcite should have it's own annotations instead of carrying along someone else's.
+1
Resolved in release 1.2.0-incubating (2015-04-16)
Attaching patch, also appended to the end of my fork of Julian Hyde's calcite-618 branch.
https://github.com/ndimiduk/incubator-calcite/tree/calcite-618