Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

[09:52:17 CST(-0600)] <jwennmacher> sure. no problem (smile)

[09:53:42 CST(-0600)] <jwennmacher> part (b) is that once you have that data, you want to sort it into columns for the report. Currently the method BaseStatisticsReport.buildAggregationReport sorts data into columns purely by AggregatedGroupMapping. To support the use case of selecting multiple tabs I need to sort data into columns by two criteria; AggregatedGroupMapping + AggreatedTabMapping.

[09:54:05 CST(-0600)] <jwennmacher> My proposal is one way of handling that

[10:18:44 CST(-0600)] <EricDalquist> ok jwennmacher

[10:18:46 CST(-0600)] <EricDalquist> back

[10:21:27 CST(-0600)] <EricDalquist> ok I see what you're talking about and you are right

[10:21:33 CST(-0600)] <EricDalquist> there is some support for multiple columns

[10:21:38 CST(-0600)] <EricDalquist> which LoginTotals uses

[10:21:49 CST(-0600)] <EricDalquist> but that assumes it is multiple columns per aggregation object

[10:21:54 CST(-0600)] <jwennmacher> correct

[10:21:57 CST(-0600)] <EricDalquist> but that isn't the case here

[10:22:11 CST(-0600)] <EricDalquist> ok ... more reading ...

[10:22:26 CST(-0600)] <jwennmacher> sure (smile) thanks for looking at this

[10:22:43 CST(-0600)] <EricDalquist> no problem

[10:22:50 CST(-0600)] <EricDalquist> thanks for doing all the hard parts (wink)

[10:23:22 CST(-0600)] <EricDalquist> so it looks like the existing getColumnDescriptions method should work. For each group you can add one column per selected tab as specified in the form

[10:24:54 CST(-0600)] <jwennmacher> yes that part would work.

[10:25:50 CST(-0600)] <EricDalquist> and I think your solution from that email looks good

[10:26:13 CST(-0600)] <jwennmacher> Thanks

[10:26:33 CST(-0600)] <jwennmacher> I appreciate you looking at it!

[10:26:45 CST(-0600)] <EricDalquist> and I agree that once this work is done we can review the overall object hierarchy and see what we can do to simplify it

[10:27:03 CST(-0600)] <EricDalquist> the current aggregation /aggregationKey stuff is more dictated by the actual event aggregation side of things

[10:27:09 CST(-0600)] <EricDalquist> to make that as efficient as possible

[10:27:45 CST(-0600)] <jwennmacher> makes sense

[10:28:22 CST(-0600)] <jwennmacher> the collection/aggregation has to be fast. Reports, not so much (smile)

[10:28:44 CST(-0600)] <EricDalquist> yeah

[10:28:57 CST(-0600)] <EricDalquist> well and realistically the only slow part of reporting is the database query

[10:29:19 CST(-0600)] <EricDalquist> so that is more making sure we can get as much data as possible for the final report with as few db queries as possible

[10:31:11 CST(-0600)] <jwennmacher> Thanks for all your feedback and help. I'll make these changes and see how it goes.

[10:31:43 CST(-0600)] <EricDalquist> sounds good