[09:47:48 CST(-0600)] <jwennmacher> EricDalquist: Goog morning
[09:47:53 CST(-0600)] <EricDalquist> good morning
[09:47:54 CST(-0600)] <jwennmacher> Good morning
[09:47:56 CST(-0600)] <jwennmacher> 
[09:48:01 CST(-0600)] <EricDalquist> I'm slowly reading through your email
[09:48:11 CST(-0600)] <jwennmacher> Sorry - too long of an email
[09:48:18 CST(-0600)] <EricDalquist> no problem
[09:48:19 CST(-0600)] <jwennmacher> You can ignore the future refactor part
[09:48:21 CST(-0600)] <EricDalquist> I'm also still waking up
[09:48:31 CST(-0600)] <jwennmacher> I understand completely
[09:49:02 CST(-0600)] <jwennmacher> I hope my explanations aren't too confusing...
[09:50:11 CST(-0600)] <jwennmacher> Does the problem discussed in (b) make sense?
[09:50:20 CST(-0600)] <EricDalquist> so this is an extension of what we talked about last week right?
[09:50:24 CST(-0600)] <jwennmacher> yes
[09:51:21 CST(-0600)] <jwennmacher> part (a) is what we discussed; adding a set of <K extends BaseAggregationK> to the DAOs so the query can include a set of tabs ids (in this particular case). This is done
[09:51:55 CST(-0600)] <EricDalquist> ok ... just a sec have to review something else for my manager
[09:52:17 CST(-0600)] <jwennmacher> sure. no problem
[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 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 
[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
[10:28:44 CST(-0600)] <EricDalquist> yeah