[12:54:13 CDT(-0500)] <b-sure> Hello uPortal Devs: I've got an error in our dev environment for a user http://pastebin.com/raw.php?i=WuEDACjB do you know if this is a sign of missing data or maybe a corrupt layout?
[12:58:59 CDT(-0500)] <EricDalquist> weird
[12:59:00 CDT(-0500)] <EricDalquist> yeah
[12:59:03 CDT(-0500)] <EricDalquist> must be an invalid layout
[12:59:17 CDT(-0500)] <b-sure> should I try to reimport his layout file?
[12:59:23 CDT(-0500)] <EricDalquist> yeah
[12:59:31 CDT(-0500)] <EricDalquist> see if you get any weird warnings/errors
[12:59:34 CDT(-0500)] <b-sure> ok. I'll start w/ that. Thanks EricDalquist
[12:59:36 CDT(-0500)] <b-sure> ok
[13:37:21 CDT(-0500)] <b-sure> ok. reimporting the users layout file fixed the issue for us.
[13:38:49 CDT(-0500)] <b-sure> EricDalquist. I think you mentioned last week that you have made some adjustments to the 3.2-patches export routine. Are those available in the github repo? I'd like to try them and then do an import of the data to 4.x
[13:45:51 CDT(-0500)] <athena> EricDalquist: i'm finally back to taking a look at the login aggregation stats reporting
[13:46:05 CDT(-0500)] <athena> it looks like for days w/ no logins it doesn't return a date dimension
[13:46:09 CDT(-0500)] <athena> is that the expected behavior?
[14:01:30 CDT(-0500)] <b-sure> Hi EricDalquist, I've got another layout related question: http://pastebin.com/raw.php?i=A7JJyQxQ looks like were down to our last type of import error from 3.2-patches to 4.x. Do you know if this type of issue is addressed in your recent mods to the import process?
[16:02:52 CDT(-0500)] <EricDalquist> athena / b-sure I'm back
[16:02:54 CDT(-0500)] <EricDalquist> athena: yes
[16:03:14 CDT(-0500)] <EricDalquist> though you could probably add some logic to the aggregator to change that behavior and populate empty rowsa
[16:08:51 CDT(-0500)] <EricDalquist> 0 5 * * 2
[16:08:55 CDT(-0500)] <EricDalquist> does that look right?
[16:09:05 CDT(-0500)] <EricDalquist> 5am every Tuesday
[16:21:10 CDT(-0500)] <athena> yes, i think that makes sense
[16:21:15 CDT(-0500)] <athena> so yes, i think we do want empty rows
[16:21:17 CDT(-0500)] <EricDalquist> oops
[16:21:19 CDT(-0500)] <athena> otherwise the graphs don't really make sense
[16:21:21 CDT(-0500)] <EricDalquist> wrong chat window for that cron stuff
[16:21:25 CDT(-0500)] <athena> lol
[16:22:10 CDT(-0500)] <athena> so either we need the aggregator to drop down 0-value rows, or we need to have special handling when we do graphing
[16:22:43 CDT(-0500)] <EricDalquist> well from a DB space saving PVO
[16:22:45 CDT(-0500)] <EricDalquist> POV*
[16:22:50 CDT(-0500)] <EricDalquist> I like missing rows 
[16:23:04 CDT(-0500)] <EricDalquist> when the DAO returns the result it could run through the List
[16:23:07 CDT(-0500)] <EricDalquist> and fill in gaps
[16:24:06 CDT(-0500)] <athena> yeah
[16:27:47 CDT(-0500)] <EricDalquist> I know it may not seem like much but over the years having sparse data will really help
[16:28:21 CDT(-0500)] <athena> yeah
[16:28:23 CDT(-0500)] <athena> that makes sense
[16:31:05 CDT(-0500)] <EricDalquist> yay comcast
[16:37:27 CDT(-0500)] <athena> no kidding.
[16:37:30 CDT(-0500)] * athena screams
[16:38:35 CDT(-0500)] <athena> clearly they're having a bad day - i'm on the edge of migrating to a coffee shop or UW campus or something
[16:38:35 CDT(-0500)] <athena> so w/ the DAO
[16:38:35 CDT(-0500)] <athena> i guess we might need a new LoginAggregation implementation?
[16:38:35 CDT(-0500)] <athena> so that we can construct new aggregations that aren't JPA-persisted?
[16:40:03 CDT(-0500)] <EricDalquist> sure ... I'd probably create a EmptyLoginAggregation implements LoginAggregation
[16:40:11 CDT(-0500)] <EricDalquist> and have a singleton INSTANCE of it
[16:40:22 CDT(-0500)] <athena> sounds terrific - along the lines of what i was thinking
[16:40:36 CDT(-0500)] <athena> like the suggestion about the singleton
[16:40:36 CDT(-0500)] <EricDalquist> then add some logic in the display code
[16:40:53 CDT(-0500)] <EricDalquist> that would run through the list and fill in blanks
[16:40:56 CDT(-0500)] <athena> yeah
[16:41:01 CDT(-0500)] <EricDalquist> if I was really feeling enterprising ...
[16:41:03 CDT(-0500)] <athena> do we want that in the display code or the dao?
[16:41:14 CDT(-0500)] <EricDalquist> display code
[16:41:16 CDT(-0500)] <athena> ok
[16:41:20 CDT(-0500)] <EricDalquist> let the DAO represent what is actually in the data
[16:41:28 CDT(-0500)] <athena> well, in that case we don't actually need an aggregation at all
[16:41:35 CDT(-0500)] <athena> since the display models things as a google DataTable
[16:41:44 CDT(-0500)] <EricDalquist> Ah
[16:41:51 CDT(-0500)] <EricDalquist> well the reason I was thinking an aggreagation is
[16:41:59 CDT(-0500)] <EricDalquist> I'd consider adding an abstract method to AggregationInterval