Uploaded image for project: 'Hawkular Metrics'
  1. Hawkular Metrics

Refactor Metric and MetricData class hierarchies


    • Type: Enhancement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 0.4.0
    • Component/s: Core
    • Labels:


      We currently have the abstract class Metric and subclasses Availability and Gauge. The subclasses serve no purpose other than being type discriminators. They provide no additional, type-specific functional. Instead they cause some bloat in the code base.

      I propose the following changes with this ticket.

      • Do away with the Gauge and Availability subclasses and make Metric concrete.
      • Turn Metric into an interface and rename the current class to MetricImpl
      • Rename MetricData to DataPoint and make it an interface

      For DataPoint we would have something like,

      interface DataPoint<T> {
          // Note that the timeUUID, writeTime, and ttl fields are no longer part of the
          // API. Those are all implementation details that do no belong in the public
         // API.
          long getTimestamp();
          T getValue();
          Map<String, String> getTags();
      interface GaugeDataPoint extends DataPoint<Double> {
          Double getValue();
      interface AvailabilityDataPoint extends DataPoint<AvailabilityType> {
          AvailabilityType getValue();
      interface CounterDataPoint extends DataPoint<Long> {
          Long getValue();

      and for Metric something like,

      interface Metric<T extends DataPoint> {
          // Note that the dpart field has been removed. It is an implementation
          // detail of the storage layer and does not belong in the domain model API.
          // Also note that there is no tenantId property. That is being incorporated
          // into MetricId.
          MetricId getId();
          Map<String, String> getTags();
          List<T> getDataPoints();
          Integer getDataRetention(); 

      This provides a much cleaner separation between API and implementation than we currently have, which can make it a bit difficult to understand what exactly is the public API.

      Lastly, it should be noted that these changes should not involve any changes to the REST API. They will however, require changes to handler methods to use the new interfaces and classes.

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  john.sanda John Sanda
                  john.sanda John Sanda
                • Votes:
                  0 Vote for this issue
                  2 Start watching this issue


                  • Created: