Conversation
…are common time stamp
Current coverage is 36.07% (diff: 80.39%)@@ master #81 diff @@
==========================================
Files 225 226 +1
Lines 12585 12636 +51
Methods 0 0
Messages 0 0
Branches 2131 2142 +11
==========================================
+ Hits 4524 4558 +34
- Misses 7490 7500 +10
- Partials 571 578 +7
|
@saaja-sfdc |
@saaja-sfdc @bsura after login usage: You may keep chaining other transform with any constants after that. Let me know if it helps. |
@aertoria Can we close this pull request? We already have a GroupBy Transform that should be able to achieve this. Also if we are adding this Transform, then it should probably be done the way we had discussed it the other day. |
As we discussed the other one will be ready for you to pull in about 1 week. But before that if you have something ready to ship then just close this one. Thanks |
Check out this PR which has already been submitted. |
Closing this one. |
Thanks |
Adding New Iterator Transform: foreach
Syntax example:
OLD:
SUM(SCALE(-10d:M:cpu{device=*}:avg, -10d:M:count{device=*}:avg))
NEW:
SUM(foreach(-10d:M:cpu{device=*}:avg,-10d:M:count{device=*}:avg,$device,$SCALE))
Scope: Can apply on any existing TRANSFORM with their existing constants requirement if any.
Detail:
foreach is implemented against a new type "TRANSFORMITERATOR", which extends current type "TRANSFORM". This architecture allows "foreach" being treated same way in metricReader and factory. However, they are different in that:
CURRENT TYPE Transform.transform:
taking Array<Metric>, giving Array<Metric>
NEW TYPE TransformIterator.iterate:
taking Array<Metric>, giving Array<TransformExecutable>
in above, each TransformExecutable is
Array<Metric>
, so they that can be consumed directly by any Transform.transform