[
https://issues.apache.org/jira/browse/TINKERPOP3-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522143#comment-14522143
]
Matthias Broecheler commented on TINKERPOP3-651:
------------------------------------------------
My preferred option would be {{Profileable}} interface as a marker which
injects a {{MutableMetrics}} object for that particular step. That way, the
vendor has less stuff to deal with. It's already a pain to optimize traversals.
If I have to write another strategy just to work out the profiling it will
become a pain for future upgrades to TP3 since its so intertwined with what the
vendor needs to do.
Also, that eliminates the need for the vendor to figure out what MutableMetrics
object to retrieve and that sort of stuff. Easiest approach all around, I
think. And since custom profiling does require the vendor to actively implement
it, adding an interface isn't a problem.
> TraversalMetrics framework is not sufficient for vendor extension
> -----------------------------------------------------------------
>
> Key: TINKERPOP3-651
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-651
> Project: TinkerPop 3
> Issue Type: Bug
> Components: process
> Reporter: Bob Briody
> Assignee: Bob Briody
> Priority: Minor
> Fix For: 3.0.0.GA
>
>
> The StandardTraversalMetrics class must provide the necessary getters to
> enable a vendor to augment the Metrics data.
> As of right now the API is missing a way for vendors to obtain the actual
> (not computed) metrics.
> In order to ensure there are no other omissions, there should be a test case
> that mocks a vendor's behavior and augments the TraversalMetrics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
