Uploaded image for project: 'Hawkular Metrics'
  1. Hawkular Metrics
  2. HWKMETRICS-113

Refactor Metric and MetricData class hierarchies

    XMLWordPrintable

    Details

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

      Description

      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> {
          @Override
          Double getValue();
      }
      
      interface AvailabilityDataPoint extends DataPoint<AvailabilityType> {
          @Override
          AvailabilityType getValue();
      }
      
      interface CounterDataPoint extends DataPoint<Long> {
          @Override
          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

          Attachments

            Issue Links

              Activity

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: