[07:49:02 CST(-0600)] <dd> hello
[07:52:53 CST(-0600)] <Arvids> hi
[07:59:00 CST(-0600)] <dd> currently, if a user's browser session expires, they are redirected to the guest layout screen
[07:59:11 CST(-0600)] <dd> is there a way to redirect them to the portal?
[07:59:53 CST(-0600)] <dd> i've been googling and have seen people use a "Redirect channel"
[08:00:01 CST(-0600)] <dd> is that still a thing in uportal 3.2.4?
[08:00:54 CST(-0600)] <Arvids> haven't heard of such channel
[08:01:20 CST(-0600)] <dd> ok
[08:02:01 CST(-0600)] <Arvids> ... but i didn't quite get the point of your question - do you want to login users even if their session has expired?
[08:02:02 CST(-0600)] <dd> because they are still logged in at that point. going to http://portal.edu brings them back to their portal
[08:02:51 CST(-0600)] <dd> yeah, their CAS "session" must still be good
[08:03:23 CST(-0600)] <Arvids> ahh... now I get it - SSO session hasn't been expired yet, while portal's session has been expired
[08:03:29 CST(-0600)] <dd> yeah
[08:03:45 CST(-0600)] <dd> what are the default lengths of both?
[08:04:21 CST(-0600)] <dd> i guess an easy way would be to make them both the same length?
[08:04:25 CST(-0600)] <Arvids> length of portal session can be configured in web.xml (under uPortal/WEB-INF/web.xml or server-scope at <tomcat>/conf/web.xml
[08:04:53 CST(-0600)] <Arvids> but i'm not familiar with configuring CAS (we're using OpenAM)
[08:06:42 CST(-0600)] <dd> ok, uportal looks to be 30 minutes. that sound right?
[10:06:40 CST(-0600)] <Arvids> anyone knows why property placeholder config in portlet context isn't inherited from application context?
[10:07:28 CST(-0600)] <EricDalquist> so you have a placeholder set in appCtx but not in portletCtx
[10:07:37 CST(-0600)] <EricDalquist> and there is no placeholder resolution happening in portletCtx?
[10:08:00 CST(-0600)] <Arvids> i'm working with sitemap currently
[10:08:55 CST(-0600)] <Arvids> ... and @Value annotation caused sitemap to be unaccessible
[10:09:14 CST(-0600)] <EricDalquist> and you have the property set?
[10:09:33 CST(-0600)] <Arvids> of course
[10:09:58 CST(-0600)] <EricDalquist> try doing @Value("$ ")
[10:10:10 CST(-0600)] <Arvids> adding explicit "<context:property-placeholder location="classpath:/properties/portal.properties"/>" in portlet context fixes the problem
[10:10:12 CST(-0600)] <EricDalquist> just to see if that gets resolved correctly and the default value gets set
[10:11:49 CST(-0600)] <Arvids> ... strange... I've had the same issue while working with our local portlets and I resolved it by redeclaring property placeholder in portlet context (just like now)
[10:11:59 CST(-0600)] <EricDalquist> huh
[10:12:03 CST(-0600)] <EricDalquist> maybe it doesn't get inherited
[10:12:28 CST(-0600)] <Arvids> well... the strangest thing is that it gets inherited... but not always
[10:12:38 CST(-0600)] <Arvids> i'm not aware of the details why, though 
[10:14:36 CST(-0600)] <EricDalquist> yeah, weird
[10:17:10 CST(-0600)] <Arvids> but now it seems that sitemap will be fixed - consistent URL generation, translatable element titles, working tab groups (this is why i needed property from portal.properties)... and no sign of missing portlets
[10:17:48 CST(-0600)] <EricDalquist> woot!
[10:17:52 CST(-0600)] <EricDalquist> very cool
[10:18:04 CST(-0600)] <Arvids> have to run, though. Will create patch, apply to github and issue pull request tomorrow
[10:18:05 CST(-0600)] <EricDalquist> oh, any thoughts on the hibernate 4.0 upgrade for 4.0.3?
[10:18:11 CST(-0600)] <Arvids> +1
[12:08:33 CST(-0600)] <EricDalquist> so apparently the SQL DATE type doesn't include TZ
[12:08:39 CST(-0600)] <EricDalquist> which is kinda ridiculous
[12:10:53 CST(-0600)] <EricDalquist> hrm ... apparently the sql standard doesn't address tz at all ;p
[12:14:44 CST(-0600)] <athena> ummm . . . wow, really?
[12:14:48 CST(-0600)] <EricDalquist> yeah
[12:15:23 CST(-0600)] <EricDalquist> looks like sql dates/times are all millis from epoch in utc
[12:15:40 CST(-0600)] <athena> fun 
[12:15:40 CST(-0600)] <EricDalquist> and you have to apply the TZ you want when you pull it back out
[12:15:59 CST(-0600)] <EricDalquist> this hibernate support library for jodatime has a bunch of "WithTZ" mapping types
[12:16:03 CST(-0600)] <EricDalquist> that all end up using 2 columns
[12:16:09 CST(-0600)] <EricDalquist> one for the date/time and one for the TZ offset
[12:17:06 CST(-0600)] <athena> lol
[12:17:14 CST(-0600)] <athena> that's irritating
[12:17:15 CST(-0600)] <EricDalquist> yeah
[12:17:41 CST(-0600)] <EricDalquist> yeah
[12:17:54 CST(-0600)] <EricDalquist> I'm trying to figure out how best to persist the various stuff related to events
[12:18:02 CST(-0600)] <EricDalquist> any thoughts on the hibernate/spring updates for 4.0.3?
[12:22:31 CST(-0600)] <athena> dunno
[12:22:41 CST(-0600)] <athena> is the next spring-sec actually out yet?
[12:23:00 CST(-0600)] <EricDalquist> 3.1 is out
[12:26:08 CST(-0600)] <athena> ah ok
[12:26:21 CST(-0600)] <athena> i guess as long as it seems like everything works ok i don't have a problem with it
[12:26:39 CST(-0600)] <EricDalquist> the only slightly annoying thing I ran into with it is that the auto-proxy-class default changed from falst to true
[12:26:42 CST(-0600)] <athena> imagine we don't have a lot of people writing code directly in uportal, much less code that's version-dependent
[12:26:46 CST(-0600)] <EricDalquist> and I had to go set that in a few places
[12:26:50 CST(-0600)] <athena> ah
[12:26:54 CST(-0600)] <EricDalquist> since we don't bundle cglib
[12:26:56 CST(-0600)] <EricDalquist> yeah
[12:27:05 CST(-0600)] <EricDalquist> I have it working and haven't seen any other problems
[12:27:18 CST(-0600)] <EricDalquist> and it will make our long term support of the event aggregation schema better
[12:33:18 CST(-0600)] <athena> that's good 
[12:33:42 CST(-0600)] <EricDalquist> oh and google data vis apis ...
[12:33:51 CST(-0600)] <EricDalquist> should I return a datatable object?
[12:33:55 CST(-0600)] <athena> no, i don't think so
[12:34:04 CST(-0600)] <EricDalquist> I think I have a spring View object that handles those nicely
[12:34:23 CST(-0600)] <EricDalquist> ok, so if not that, how should the data be structured?
[12:34:38 CST(-0600)] <athena> seems like just the aggregation objects have the right info?
[12:34:45 CST(-0600)] <EricDalquist> they do
[12:34:48 CST(-0600)] <EricDalquist> so a list of those is fine?
[12:34:52 CST(-0600)] <athena> yeah, i think that'd be best
[12:34:55 CST(-0600)] <EricDalquist> ok
[12:34:57 CST(-0600)] <EricDalquist> easy enough
[12:35:02 CST(-0600)] <athena> i hate to put the google datatables down quite so deep in the APIs
[12:35:12 CST(-0600)] <EricDalquist> yeah
[12:35:19 CST(-0600)] <athena> especially given the way they've treated their APIs
[12:35:25 CST(-0600)] <EricDalquist> yeah
[12:35:36 CST(-0600)] <athena> don't want to make our code not compile if they change everything (which they probably will . . . )
[12:35:49 CST(-0600)] <EricDalquist> I had an argument with them via an issue tracker over some changes in guava
[12:36:27 CST(-0600)] <athena> how'd that go?
[12:36:40 CST(-0600)] <EricDalquist> no where
[12:37:13 CST(-0600)] <EricDalquist> http://code.google.com/p/guava-libraries/issues/detail?id=881
[12:37:19 CST(-0600)] <EricDalquist> essentially they deprecated an API in r10
[12:37:23 CST(-0600)] <EricDalquist> and replaced it in R11
[12:37:28 CST(-0600)] <EricDalquist> but there is no release that has both old and new
[12:37:39 CST(-0600)] <EricDalquist> which makes upgrading hard since some other libraries use the old API
[12:37:43 CST(-0600)] <EricDalquist> everything has to move together
[12:37:52 CST(-0600)] <athena> lol
[12:37:53 CST(-0600)] <athena> no kidding.
[13:31:48 CST(-0600)] <EricDalquist> athena: should new guest sessions create LoginEvents?
[14:02:18 CST(-0600)] <athena> hmmm.
[14:02:39 CST(-0600)] <athena> my instinct is to want to record session creation events for them but not login events
[14:02:43 CST(-0600)] <athena> do we have such a distinction?
[14:02:49 CST(-0600)] <EricDalquist> we don't right now
[14:03:20 CST(-0600)] <EricDalquist> I've thought about splitting them out but I'm not really sure the best way
[14:03:30 CST(-0600)] <EricDalquist> for guest users you'd just have a SessionCreated event
[14:03:42 CST(-0600)] <EricDalquist> for authd you'd have SessionCreated and Login
[14:03:45 CST(-0600)] <athena> yeah
[14:03:54 CST(-0600)] <athena> i mean i guess if we didn't have that then yes, we'd want a login event
[14:04:05 CST(-0600)] <EricDalquist> though if we want to capture the groups the user is in we should probably do that in the SessionCreated event
[14:04:13 CST(-0600)] <EricDalquist> since even guests can have interesting groups
[14:05:58 CST(-0600)] <EricDalquist> so I guess that is where I get stuck
[14:06:14 CST(-0600)] <EricDalquist> what is the real difference between session creation and login
[14:06:24 CST(-0600)] <EricDalquist> I guess login is the explicit auth request
[14:19:07 CST(-0600)] <athena> yeah
[14:19:09 CST(-0600)] <athena> i think so
[14:19:23 CST(-0600)] <athena> hmm.
[14:19:39 CST(-0600)] <athena> heh, not even quite sure how to get data for my most simple use case here
[14:19:47 CST(-0600)] <EricDalquist> ?
[14:19:56 CST(-0600)] <athena> was thinking i'd start small and just do a pie chart of login groups
[14:20:19 CST(-0600)] <EricDalquist> ah, like logins per groups for a time period?
[14:20:23 CST(-0600)] <athena> yeah
[14:20:31 CST(-0600)] <athena> what do you think the best way to select a time period would be though?
[14:20:43 CST(-0600)] <athena> especially for testing, not necessarily a lot of data
[14:20:46 CST(-0600)] <EricDalquist> well, what sort of time period do you want to display?
[14:20:57 CST(-0600)] <athena> does the aggregator aggregate times before the time period is up?
[14:21:00 CST(-0600)] <EricDalquist> like logins per group for a specific week?
[14:21:01 CST(-0600)] <EricDalquist> yes
[14:21:06 CST(-0600)] <athena> like if i asked for data for the last month, would it give it to me?
[14:21:09 CST(-0600)] <EricDalquist> it updates them as it goes
[14:21:11 CST(-0600)] <EricDalquist> yup
[14:21:14 CST(-0600)] <athena> oh awesome
[14:21:15 CST(-0600)] <athena> ok.
[14:21:27 CST(-0600)] <athena> so would it give it to me even if the aggregation hadn't been running for a month?
[14:21:38 CST(-0600)] <athena> so i could say a month from right now, or whatever?
[14:22:13 CST(-0600)] <EricDalquist> right
[14:22:19 CST(-0600)] <EricDalquist> so if you started running your portal today
[14:22:34 CST(-0600)] <EricDalquist> there will be an aggregation with a DateDimension of Jan 1 2012
[14:22:42 CST(-0600)] <EricDalquist> for the MONTH interval
[14:23:09 CST(-0600)] <EricDalquist> which would have the total and unique login counts for this month
[14:23:34 CST(-0600)] <athena> awesome
[14:23:39 CST(-0600)] <athena> so something like:
[14:23:40 CST(-0600)] <athena> DateDimension date = dateDimensionDao.getDateDimensionByDate(new DateMidnight());
[14:23:40 CST(-0600)] <athena> TimeDimension time = timeDimensionDao.getTimeDimensionByTime(new LocalTime());
[14:23:40 CST(-0600)] <athena> Set<? extends LoginAggregation> aggrs = loginDao.getLoginAggregationsForInterval(date, time, Interval.MONTH);
[14:23:44 CST(-0600)] <athena> does that seem plausible?
[14:23:55 CST(-0600)] <EricDalquist> ah yeah
[14:24:22 CST(-0600)] <EricDalquist> I think there may end up being either sub-selects or utility methods on the dimension daos
[14:24:45 CST(-0600)] <EricDalquist> since you need to answer they "give me the first DateDimension in interval X for DateMidnight Y"
[14:24:59 CST(-0600)] <EricDalquist> since that is the DateDimension you need to actually query with
[14:25:38 CST(-0600)] <athena> not sure i'm following
[14:26:08 CST(-0600)] <EricDalquist> so in the DB each LoginAggregation row has a reference to a DateDimension and a TimeDimension
[14:26:39 CST(-0600)] <EricDalquist> there is no MONTH aggregate for the DateDimension(JAn 23, 2012)
[14:26:43 CST(-0600)] <EricDalquist> oh ... dug
[14:26:45 CST(-0600)] <EricDalquist> duh
[14:26:47 CST(-0600)] <EricDalquist> just a sec
[14:26:58 CST(-0600)] <athena> oh oops.
[14:27:06 CST(-0600)] <EricDalquist> I have an easy solution
[14:27:10 CST(-0600)] <athena> meant to do datemidnight - one month, or whatever jodatime does for that
[14:27:12 CST(-0600)] <EricDalquist> just need to smack eclipse a few times first
[14:27:12 CST(-0600)] <athena> would that work?
[14:27:20 CST(-0600)] <EricDalquist> it does, for months
[14:27:24 CST(-0600)] <athena> clearly i need to eat lunch
[14:27:24 CST(-0600)] <EricDalquist> but there is a helper class
[14:27:26 CST(-0600)] <athena> ooh
[14:27:27 CST(-0600)] <EricDalquist> that does this all for you
[14:27:39 CST(-0600)] <EricDalquist> since for things like weeks, quarters and terms it isn't so simple
[14:28:03 CST(-0600)] <EricDalquist> Inject IntervalHelper
[14:28:07 CST(-0600)] <EricDalquist> IntervalInfo getIntervalInfo(Interval interval, DateTime date)
[14:28:33 CST(-0600)] <EricDalquist> so you do: IntervalInfo info = intervalHelper.getIntervalInfo(Interval.MONTH, new DateTime());
[14:28:35 CST(-0600)] <athena> ahh, excellent
[14:28:44 CST(-0600)] <athena> yes that sounds much cleaner
[14:28:45 CST(-0600)] <athena> thanks!
[14:29:09 CST(-0600)] <EricDalquist> IntervalInfo is a simple pojo that consists of the start DateTime (inclusive), end DateTime (exclusive), start DateDimension, and start TimeDimension
[14:29:33 CST(-0600)] <EricDalquist> use those date/time dimensions objects in your query against the login aggregates
[14:30:01 CST(-0600)] <athena> excellent
[14:30:17 CST(-0600)] <EricDalquist> and that will work correctly for all intervals
[14:30:41 CST(-0600)] <EricDalquist> note that info requests for ACADEMIC_TERM will return null if no term configuration has been done
[14:31:05 CST(-0600)] <EricDalquist> eclipse is NOT cooporating today
[14:32:05 CST(-0600)] <EricDalquist> also in the login aggregation model the duration property is the number of minutes in the aggregated interval
[14:32:10 CST(-0600)] <EricDalquist> that field is updated as aggregation is done
[14:32:37 CST(-0600)] <EricDalquist> so for things like the current month it tells you the number of minutes from the start of the month to the most recently aggregated event
[14:32:50 CST(-0600)] <athena> i hate when eclipse misbehaves
[14:33:13 CST(-0600)] <EricDalquist> my work machine in general is getting bad
[14:33:45 CST(-0600)] <EricDalquist> and I'm loathe to upgrade to the latest ubuntu ... need to find a new linux distro I guess
[14:43:34 CST(-0600)] <athena> oh ubuntu not working out well right now?
[14:43:56 CST(-0600)] <EricDalquist> well my current install seems to be getting flakier
[14:44:05 CST(-0600)] <EricDalquist> and upgrading would mean the unity interface
[14:44:07 CST(-0600)] <EricDalquist> which I've tried
[14:44:11 CST(-0600)] <EricDalquist> and don't want any part of
[14:44:25 CST(-0600)] <athena> ahh
[14:44:29 CST(-0600)] <athena> ooh the chart works!
[14:44:36 CST(-0600)] <athena> of course, actually this chart makes no sense whatsoever
[14:44:39 CST(-0600)] <EricDalquist> lol
[14:44:43 CST(-0600)] <athena> since groups aren't mutually exclusive
[14:44:45 CST(-0600)] <athena> but hey, a graph!
[14:44:47 CST(-0600)] <EricDalquist> yup
[14:44:52 CST(-0600)] <athena> mmmm shiny colors
[14:44:53 CST(-0600)] <athena> ok.
[14:44:55 CST(-0600)] <EricDalquist> are you just doing straight sql?
[14:44:57 CST(-0600)] <athena> no
[14:45:08 CST(-0600)] <EricDalquist> oh even better
[14:45:16 CST(-0600)] <athena> yes, except for the uselessness
[14:45:23 CST(-0600)] <EricDalquist> lol
[14:45:26 CST(-0600)] <athena> so i guess now what i really need to do is go use JPA to add some new methods to the DAO so we can make charts that make sense?
[14:45:34 CST(-0600)] <EricDalquist> well maybe a nice line chart of logins/unique logins over time
[14:45:47 CST(-0600)] <athena> yeah, that's exactly my thought
[14:45:57 CST(-0600)] <athena> actually this current chart would be ok as a bar chart
[14:46:04 CST(-0600)] <EricDalquist> yeah
[14:46:07 CST(-0600)] <athena> but yeah, graphing logins/time period would be good
[14:46:39 CST(-0600)] <EricDalquist> https://my-reports.doit.wisc.edu/StatsReporter/reports/loginReport.html
[14:46:42 CST(-0600)] <EricDalquist> that is what we have right now
[14:46:44 CST(-0600)] <EricDalquist> agaisnt our old tool
[14:46:52 CST(-0600)] <EricDalquist> my only gripe is I want one more option
[14:46:58 CST(-0600)] <athena> so i probably need a DAO that returns something like what we have now, but returns a list of aggregation objects across some time period
[14:47:01 CST(-0600)] <EricDalquist> to say if I want total, unique or both
[14:47:07 CST(-0600)] <athena> yeah
[14:47:07 CST(-0600)] <EricDalquist> yeah
[14:47:12 CST(-0600)] <athena> this is exactly the kidn of thing i was thinking
[14:47:27 CST(-0600)] <athena> thinking we might want it to get data via ajax so it auto-updates when you select different options?
[14:47:43 CST(-0600)] <EricDalquist> yup
[14:47:54 CST(-0600)] <athena> CSV export - that's a good feature too
[14:48:00 CST(-0600)] <EricDalquist> yeah
[14:48:12 CST(-0600)] <EricDalquist> that is done using the google DataTable object
[14:48:23 CST(-0600)] <EricDalquist> do you have a google data vis spring view?
[14:48:30 CST(-0600)] <EricDalquist> if not I'll dig up the one we have here
[14:49:16 CST(-0600)] <athena> oh no, i don't
[14:49:21 CST(-0600)] <athena> that sounds like that'd be a good compromise
[14:49:31 CST(-0600)] <EricDalquist> that is what that site is using
[14:49:38 CST(-0600)] <EricDalquist> stuff the data into a DataTAble and stick it in the model
[14:49:41 CST(-0600)] <athena> yeah
[14:49:45 CST(-0600)] <EricDalquist> then the view renders it as json, csv or html
[14:50:18 CST(-0600)] <athena> so we can have the actual chart rendering in the view layer
[14:50:27 CST(-0600)] <athena> and have the datatable be the model that comes back from the controller
[14:50:45 CST(-0600)] <athena> that way the datatable isn't too far into the DAO, but we're not doing a bunch of manual wiring inline in the JSP either
[14:50:51 CST(-0600)] <EricDalquist> https://gist.github.com/1665478
[14:51:00 CST(-0600)] <EricDalquist> sounds great
[14:51:35 CST(-0600)] <EricDalquist> and then with that view you have URLs like:
[14:51:36 CST(-0600)] <EricDalquist> https://my-reports.doit.wisc.edu/StatsReporter/reports/loginReportData?startDate=01%2F01%2F2012&endDate=01%2F31%2F2012&statsGroups=0&interval=3&tqx=out:html
[14:51:36 CST(-0600)] <EricDalquist> https://my-reports.doit.wisc.edu/StatsReporter/reports/loginReportData?startDate=01%2F01%2F2012&endDate=01%2F31%2F2012&statsGroups=0&interval=3&tqx=out:csv
[14:52:03 CST(-0600)] <EricDalquist> the tqx parameter is read by the DataSourceRequest/DataSourceHelper
[14:52:09 CST(-0600)] <EricDalquist> and renders the appropriate output
[14:52:46 CST(-0600)] <athena> awesome, thanks
[14:52:59 CST(-0600)] <athena> so probably the hard part here is me figuring out all the JPA criteria stuff
[14:53:11 CST(-0600)] <EricDalquist> yeah
[14:53:16 CST(-0600)] <EricDalquist> let me know if you want a hand with that
[14:53:28 CST(-0600)] <EricDalquist> I usually write the SQL first and get that working
[14:53:38 CST(-0600)] <EricDalquist> then translate it to the criteria builder
[14:53:53 CST(-0600)] <EricDalquist> oh and the JS that displays the chart and uses that view is just in the source of the page: https://my-reports.doit.wisc.edu/StatsReporter/reports/loginReport.html
[14:54:27 CST(-0600)] <athena> awesome, thanks
[15:38:40 CST(-0600)] <athena> ok.
[15:38:55 CST(-0600)] <athena> i'm thinking we need to get loginaggregationimpl to extend comparable?
[15:39:11 CST(-0600)] <EricDalquist> sounds reasonable
[15:39:15 CST(-0600)] <athena> er
[15:39:16 CST(-0600)] <EricDalquist> to sort them by date/time?
[15:39:17 CST(-0600)] <athena> datedimension
[15:39:19 CST(-0600)] <athena> but probably that too
[15:39:29 CST(-0600)] <EricDalquist> yeah
[15:39:41 CST(-0600)] <athena> right now i can't actually do before/after queries
[15:39:50 CST(-0600)] <athena> assuming that's because the field isn't comparable
[15:39:54 CST(-0600)] <EricDalquist> really?
[15:39:59 CST(-0600)] <EricDalquist> can you paste an example
[15:41:06 CST(-0600)] <athena> cb.greaterThanOrEqualTo(root.get(LoginAggregationImpl_.dateDimension), this.dateDimensionParameter),
[15:41:06 CST(-0600)] <athena> cb.lessThan(root.get(LoginAggregationImpl_.dateDimension), this.date2DimensionParameter),
[15:41:06 CST(-0600)] <athena> cb.equal(root.get(LoginAggregationImpl_.interval), this.intervalParameter)
[15:41:27 CST(-0600)] <athena> this looks like it expects the expression to extend comparable: http://docs.oracle.com/javaee/6/api/javax/persistence/criteria/CriteriaBuilder.html#lessThanOrEqualTo(javax.persistence.criteria.Expression, javax.persistence.criteria.Expression)
[15:41:27 CST(-0600)] <EricDalquist> ah .... right
[15:41:35 CST(-0600)] <EricDalquist> so that isn't the issue
[15:41:44 CST(-0600)] <EricDalquist> it is that the query requires a join
[15:41:54 CST(-0600)] <EricDalquist> the table for LoginAggregationImpl has no date or time info in it
[15:42:00 CST(-0600)] <EricDalquist> that is all stored in the dimension tables
[15:42:15 CST(-0600)] <EricDalquist> so you need to actually query for the list of date dimensions in the range
[15:42:30 CST(-0600)] <EricDalquist> and then join in the corresponding login aggregations
[15:43:23 CST(-0600)] <athena> ugh.
[15:43:31 CST(-0600)] <athena> yeah, i'm just not familiar with this API whatsoever
[15:43:37 CST(-0600)] <athena> this api meaning the criteria builder
[15:43:54 CST(-0600)] <EricDalquist> are you comfortable with how you would write that SQL?
[15:44:08 CST(-0600)] <athena> vaguely
[15:44:15 CST(-0600)] <athena> i don't know our new API either, apparently
[15:44:43 CST(-0600)] <athena> seems like i hardly ever use SQL anymore
[15:44:50 CST(-0600)] <athena> though certainly this is a good reason to catch up
[15:46:44 CST(-0600)] <EricDalquist> https://gist.github.com/1665699
[15:46:49 CST(-0600)] <EricDalquist> that is about what the SQL would look like
[15:46:58 CST(-0600)] <EricDalquist> the criteria builder adds some verbosity
[15:47:06 CST(-0600)] <EricDalquist> but the result reads pretty close to the SQL
[15:47:39 CST(-0600)] <EricDalquist> the big difference is that where clause would look more like "where dd.date >= startDate and dd.date <= endDate"
[15:47:52 CST(-0600)] <EricDalquist> but that was harder to write in an actually functional sql example
[15:48:41 CST(-0600)] <athena> ok, i think that makes sense
[15:49:10 CST(-0600)] <EricDalquist> so the first thing you're interested is actually the date range
[15:49:13 CST(-0600)] <athena> so we're going to wind up with some pretty complex queries to get the right date range back
[15:49:30 CST(-0600)] <EricDalquist> yes
[15:49:36 CST(-0600)] <athena> ick.
[15:49:42 CST(-0600)] <EricDalquist> an unfortunate side effect of the dimensionality
[15:49:49 CST(-0600)] <EricDalquist> which is needed to reduce the number of rows
[15:49:49 CST(-0600)] <athena> and even worse once we start considering datetimes
[15:50:08 CST(-0600)] <EricDalquist> if we embed all the date/time info in each aggregate the number of rows starts to balloon
[15:50:21 CST(-0600)] <athena> yeah
[15:50:25 CST(-0600)] <athena> makes sense
[15:50:34 CST(-0600)] <EricDalquist> the queries do get complex
[15:51:29 CST(-0600)] <athena> yeah.
[15:51:30 CST(-0600)] <athena> hm.
[15:51:52 CST(-0600)] <athena> so honestly, before i can get anything done on this i'm probably going to need to go read a bunch about the criteria stuff
[15:52:22 CST(-0600)] <EricDalquist> would some examples help?
[15:52:59 CST(-0600)] <athena> if they were sufficiently close enough, maybe
[15:53:19 CST(-0600)] <athena> i mean i get the overall picture, but figuring out exactly how all this changes the root, etc. . . .
[15:53:32 CST(-0600)] <athena> ultimately i need to actually udnerstand what's going on, probably
[15:57:50 CST(-0600)] <EricDalquist> hrm ... there may actually be flaws in the current data model that prevents the query you want from working
[15:57:53 CST(-0600)] <EricDalquist> I'll take a pass at it
[16:05:24 CST(-0600)] <EricDalquist> yup, there isn't any way to do the query you want with the current model
[16:05:31 CST(-0600)] <EricDalquist> looks like it should be an easy fix ...
[16:12:42 CST(-0600)] <athena> that's good at least
[16:16:48 CST(-0600)] <EricDalquist> https://gist.github.com/1665818
[16:16:53 CST(-0600)] <EricDalquist> that is what it would look like I think
[16:17:07 CST(-0600)] <EricDalquist> the part that is missing is DateDimensionImpl_.loginAggregations
[16:17:10 CST(-0600)] <EricDalquist> which I've added locally
[16:17:13 CST(-0600)] <EricDalquist> I'll try testing this
[16:17:18 CST(-0600)] <EricDalquist> and if it works I'll get it committed
[16:17:35 CST(-0600)] <athena> awesome, thanks
[16:26:39 CST(-0600)] <EricDalquist> yup that works
[16:26:43 CST(-0600)] <EricDalquist> a little annoying
[16:26:59 CST(-0600)] <EricDalquist> as our date and time dimensions will now have a collection of aggregation as a field
[16:27:04 CST(-0600)] <athena> yay!
[16:27:10 CST(-0600)] <EricDalquist> but without that hibernate won't let us join
[16:27:19 CST(-0600)] <athena> yeah
[16:27:28 CST(-0600)] <athena> now i feel less bad for having a headache
[16:27:52 CST(-0600)] <EricDalquist>
[16:47:11 CST(-0600)] <EricDalquist> ok athena
[16:47:19 CST(-0600)] <EricDalquist> I just pushed the example to master
[16:47:29 CST(-0600)] <EricDalquist> I also pushed the hibernate & spring updates
[16:47:39 CST(-0600)] <EricDalquist> since those made the date dimension stuff a little easier
[16:48:09 CST(-0600)] <EricDalquist> so you'll need to run "ant db-hibernate-aggr-events db-hibernate-raw-events"