uPortal IRC Logs-2012-01-23

Owned by Apereo Infrastructure
Last updated: Jan 23, 2012Version comment
15 min read

[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("$

Unknown macro: {someProperty}

")

[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 (sad)

[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 (tongue)

[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 (tongue)

[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 (smile)

[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 (tongue)

[12:36:27 CST(-0600)] <athena> how'd that go?

[12:36:40 CST(-0600)] <EricDalquist> no where (smile)

[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 (tongue)

[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 (smile)

[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 (smile)

[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 (sad)

[14:43:34 CST(-0600)] <athena> oh (sad) 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 (tongue)

[14:44:25 CST(-0600)] <athena> ahh (smile)

[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 (smile)

[14:45:16 CST(-0600)] <athena> yes, except for the uselessness (smile)

[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&amp;endDate=01%2F31%2F2012&amp;statsGroups=0&amp;interval=3&amp;tqx=out:html

[14:51:36 CST(-0600)] <EricDalquist> https://my-reports.doit.wisc.edu/StatsReporter/reports/loginReportData?startDate=01%2F01%2F2012&amp;endDate=01%2F31%2F2012&amp;statsGroups=0&amp;interval=3&amp;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 (smile)

[14:52:59 CST(-0600)] <athena> so probably the hard part here is me figuring out all the JPA criteria stuff (tongue)

[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 (tongue)

[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 (smile)

[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 (smile)

[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 (smile)

[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 (tongue)

[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 (tongue)

[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 (smile)

[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 (sad)

[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> (smile)

[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"

[16:50:30 CST(-0600)] <athena> thanks!

[16:50:44 CST(-0600)] <EricDalquist> I updated the example to use an in clause too

[16:50:56 CST(-0600)] <EricDalquist> so the api is (start, end, interval, groups...)

[16:51:16 CST(-0600)] <EricDalquist> really the best way to figure these out is to write the SQL first

[16:51:21 CST(-0600)] <EricDalquist> then translate it into the critera api

[16:51:32 CST(-0600)] <EricDalquist> at least that is the way that is easiest for me

[16:51:43 CST(-0600)] <EricDalquist> since I get immediate feedback from the sql if it is correct or not

[16:53:00 CST(-0600)] <EricDalquist> ok, time to head home

[16:53:12 CST(-0600)] <athena> thanks (smile)_

[16:53:17 CST(-0600)] <EricDalquist> good luck with the reporting stuff (smile) JimH is very exited that other people might be writing reports (smile)

[16:53:23 CST(-0600)] <athena> yay!