[10:47:17 CDT(-0500)] <TonyUnicon> fun fact about hibernate, eagerly loading OneToMany child entities will impact search results (in the form of duplicates)
[10:53:30 CDT(-0500)] <dmccallum541> hmmmm…. specifying either DistinctResultTransformer or DistinctRootEntityResultTransformer doesn't help?
[10:55:19 CDT(-0500)] <dmccallum541> i think you'll see that going on in a few places
[10:55:25 CDT(-0500)] <dmccallum541> stuff like… criteria.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);
[10:55:32 CDT(-0500)] <dmccallum541> but i may be misunderstanding the issue
[11:06:50 CDT(-0500)] <JasonElwood> for external_course and external_course_term, is the code column at 20 char enough characters?
[11:09:44 CDT(-0500)] <JasonElwood> I spec'd 35 characters, but the db has 20. If we all think that is enough, then I can just change the spec
[11:13:36 CDT(-0500)] <dmccallum541> so
[11:14:12 CDT(-0500)] <dmccallum541> that field would usually be something like <formatted_course>_<qualifier>, right?
[11:14:40 CDT(-0500)] <dmccallum541> either that or some other synthetic ID that's totally opaque and generated by the institution
[11:15:43 CDT(-0500)] <dmccallum541> if the former it would have to be at least 35+n, where n is something we'd have to guess at for a typical <qualifier> len. when we've done that before for section_number we used '10'. so that would be 45 minimum for course_code
[11:16:08 CDT(-0500)] <dmccallum541> 46, rather, if we assume at least 1 char delim
[11:18:42 CDT(-0500)] <dmccallum541> so since we dont actually know wtf anyone is going to use, how about 64
[11:21:02 CDT(-0500)] <JasonElwood> fine with me
[11:44:34 CDT(-0500)] <JasonElwood> who wants a Jira issue with a bunch of database changes to correct columns in the external tables. It will be really fun.
[11:44:50 CDT(-0500)] <dmccallum541> i'll take it as long as it's properly labeled as such
[11:45:54 CDT(-0500)] <js70> sounds efficient.
[11:46:08 CDT(-0500)] <js70> heard thats a good thing...
[12:05:47 CDT(-0500)] <JasonElwood> SSP-1077
[12:06:48 CDT(-0500)] <dmccallum541> i feel like maybe this ticket is overpromising...
[12:10:35 CDT(-0500)] <dmccallum541> i especially like how each of the "fun" labels includes a literal comma… hinting that there's yet even more "fun" to come...
[12:13:07 CDT(-0500)] <JasonElwood> oh know. once you start, you'll be hooked
[12:46:55 CDT(-0500)] <TonyUnicon> sorry Dan, didn't read this conversation before the standup
[12:47:03 CDT(-0500)] <dmccallum54> no worries
[15:43:02 CDT(-0500)] <JasonElwood> JS- for the Main Tool schedule tab, I expect it to show courses from external_student_transcript_course for the current term (based on the date). Am I correct?
[15:52:33 CDT(-0500)] <js70> yes
[15:54:11 CDT(-0500)] <JasonElwood> do you have that working in your env?
[15:54:24 CDT(-0500)] <js70> yes
[15:55:23 CDT(-0500)] <js70> have not checked recently.
[15:55:37 CDT(-0500)] <js70> showed i for the demo
[15:58:07 CDT(-0500)] <JasonElwood> would you confirm please? I have courses in the transcript for Spring 2013. Spring is defined as 1/22/2013-5/17/2013. I expect those courses to show in the schedule tab
[15:59:30 CDT(-0500)] <js70> k
[15:59:33 CDT(-0500)] <js70> compiling now.
[16:00:40 CDT(-0500)] <js70> I would expect that as well. Perhaps how the currentTerm is determined is messed up. I'll take a look at that.
[16:08:16 CDT(-0500)] <JasonElwood> DM- a record in external_student_test with test_date = 1/1/2011 12:00:00 AM shows in SSP at 12/31/2010. Is this in scope for what you are changing?
[16:08:57 CDT(-0500)] <dmccallum54> yes
[16:09:20 CDT(-0500)] <dmccallum54> well. it's not exactly what i'm working on right now. but falls under the general umbrella of "sloppy time handling issues"
[16:10:10 CDT(-0500)] <dmccallum54> the proposal for that particular field in my original email on the topic was to modify that field so it's handled the same way as birthdate
[16:10:21 CDT(-0500)] <dmccallum54> i.e. treat it as a date with no time component
[16:11:11 CDT(-0500)] <JasonElwood> right. perfect
[16:11:22 CDT(-0500)] <dmccallum54> if we need to know exactly when a test was taken, then we can keep the current data type, but would probably want to change the on-screen representation to a timestamp. my guess is we probably only have these "date only" values
[16:11:36 CDT(-0500)] <dmccallum54> … so prob want to treat exactly the same as birth dates
[16:11:50 CDT(-0500)] <JasonElwood> date only is fine. in fact we've been removing time whenever it displayed
[16:11:55 CDT(-0500)] <dmccallum54> rock on
[16:12:17 CDT(-0500)] <dmccallum54> if you want to open a ticket for that, that's just fine