[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
[16:12:32 CDT(-0500)] <dmccallum54> external_student_financial_aid.fafsa_date is the other problem child here
[16:12:42 CDT(-0500)] <dmccallum54> w/r/t external data anyway
[16:12:51 CDT(-0500)] <JasonElwood> oh. I thought you said it was in scope already
[16:13:04 CDT(-0500)] <dmccallum54> i intend for it to be in scope
[16:13:25 CDT(-0500)] <dmccallum54> there's no ticket covering that particular field at the moment tho
[16:14:12 CDT(-0500)] <dmccallum54> there's a couple other fields that need to be thought about too… task.due_date… journal_entry.entry_date… person_disability.eligible_letter_date ...person_disability.ineligible_letter_date
[16:14:53 CDT(-0500)] <JasonElwood> you separate issues for those?
[16:15:20 CDT(-0500)] <JasonElwood> do you want separate issues for those?
[16:15:55 CDT(-0500)] <dmccallum54> um.
[16:16:21 CDT(-0500)] <dmccallum54> probably simpler to start w/ one ticket and split out later if chaos ensues
[16:16:51 CDT(-0500)] <dmccallum54> if you see a subset there that need to be handled in a special way, maybe go ahead and split those into a sep. ticket
[16:18:01 CDT(-0500)] <js70> I'm showing 3 courses for SP13
[16:18:18 CDT(-0500)] <js70> just a sec I'll get the dates
[16:18:26 CDT(-0500)] <JasonElwood> ugh.
[16:18:56 CDT(-0500)] <js70> no that's GOOD. Its working on my machine. That's all I care about.:^)
[16:20:12 CDT(-0500)] <js70> Yeah, my spring term starts in january and ends on december 31st. Thats global warming for you!
[16:22:19 CDT(-0500)] <js70> Its probably all the date stuff Dan's been working on. April/May what's the difference?
[16:22:29 CDT(-0500)] <JasonElwood> Not sure where to go. what's the query
[16:23:55 CDT(-0500)] <js70> me.doGet(personId, callbacks, me.getBaseUrl( personId ) + "/currentcourses" );
[16:26:15 CDT(-0500)] <js70> which translates to :
[16:26:17 CDT(-0500)] <js70> http://localhost:8080/ssp/api/1/person/44cf0738-728a-4213-b13e-6559cac551f6/transcript/currentcourses
[16:33:40 CDT(-0500)] <JasonElwood> I get courses back
[16:34:01 CDT(-0500)] <JasonElwood> but the term code just says spring
[16:35:55 CDT(-0500)] <js70> what should it say?
[16:36:23 CDT(-0500)] <JasonElwood> not sure, should it say Spring 2013 since that is the value in the db
[16:38:39 CDT(-0500)] <js70> k. that's the code? or the name. I am displaying the code
[16:41:15 CDT(-0500)] <JasonElwood> I take that back. It does show Spring 2013. its' just wrapped
[16:41:34 CDT(-0500)] <JasonElwood> the API returns what I expect to see. the UI doesn't show any data
[16:42:27 CDT(-0500)] <js70> so the UI does not show any courses or just doesn't display the term code properly?
[16:42:36 CDT(-0500)] <JasonElwood> doesn't show any courses
[16:43:04 CDT(-0500)] <js70> can you look at the browser debugger and see if an exception has been thrown?
[16:45:25 CDT(-0500)] <JasonElwood> no exception
[16:45:40 CDT(-0500)] <JasonElwood> the call is red, meaning slow I believe
[16:45:51 CDT(-0500)] <JasonElwood> actually, it is canceled
[16:46:14 CDT(-0500)] <js70> like a 404? or the browser just got tired of waiting?
[16:46:39 CDT(-0500)] <JasonElwood> looks like browser got tired of waiting. I'm seeing in on the caseload too. must be my env
[16:46:42 CDT(-0500)] <JasonElwood> awesome
[16:47:13 CDT(-0500)] <js70> better start feeding your hamsters. they work better on a full belly.
[16:47:41 CDT(-0500)] <JasonElwood> not sure why my system is slow
[16:49:05 CDT(-0500)] <js70> Its usually Ram
[16:49:34 CDT(-0500)] <JasonElwood> well. the machine has 32gb with 4gb dedicated to the database
[16:49:44 CDT(-0500)] <js70> that should be enough
[16:50:45 CDT(-0500)] <dmccallum54> http://books.google.com/books?id=DXMHPYZWL9kC&lpg=PA81&ots=FUaTD3ZP5-&pg=PA81#v=onepage&q&f=false
[16:51:39 CDT(-0500)] <JasonElwood> nice
[16:51:45 CDT(-0500)] <dmccallum54> classy. i know.
[17:14:31 CDT(-0500)] <JasonElwood> not to spend too much time chasing this down, but has there been anything checked-in today that could significantly decrease performance against my local SQL Server env. I'm seeing slow-downs on a few items but not everything. slow-downs to the point of timing out.
[17:16:33 CDT(-0500)] <dmccallum54> this adds a sort on external_course.formatted_course
[17:16:34 CDT(-0500)] <dmccallum54> https://github.com/Jasig/SSP/commit/205eceff05232c88f38b629267f8deaca496e32e
[17:16:50 CDT(-0500)] <dmccallum54> havent updated recently, but i doubt there's an index on that
[17:17:33 CDT(-0500)] <dmccallum54> and https://github.com/Jasig/SSP/commit/53375371f0f332141bf0f63c7b1f31aa04e63bcc changes the way plan-course bindings are loaded
[17:17:34 CDT(-0500)] <JasonElwood> that shouldn't slow down the initial caseload loading though right
[17:17:43 CDT(-0500)] <dmccallum54> initial caseload no
[17:18:41 CDT(-0500)] <dmccallum54> sure it's the caseload call that's slow? has been quite a bit of work on Main recently, which gets loaded by default for the 1st student in caseload...
[17:19:25 CDT(-0500)] <JasonElwood> very possible. the caseload doesn't load. it times out. so it could be Main attempting to load for the first student
[17:20:10 CDT(-0500)] <JasonElwood> there is a S load going on there now
[17:20:28 CDT(-0500)] <dmccallum54> um
[17:21:32 CDT(-0500)] <dmccallum54> if you're so inclined, could post a screencast.com demonstrating what you're seeing while you have chrome dev tools open, set to the network tab and XHR requests only
[18:42:27 CDT(-0500)] <JasonElwood> i did a little more testing on the caseload slowness. I'm working on the linux CI and everything loads as expected, except for the MAP box in the Main Dashboard. That shows the loading dialog until it times out. I know Jim is working on tying that area into the MAP data. But it shows that the amount of data we are adding on the Main tool can have very negative effects. Even though it should work, maybe we should consider not lo
[18:44:11 CDT(-0500)] <JasonElwood> I don't see the common use case that advisors will log into SSP to see the Main Tool for the first student in their list. Again, I know it should work fine.
[18:49:36 CDT(-0500)] <dmccallum54> js70 will probably have a more colorful take on it… but the Main tool, under our current approach, where we basically cache nothing either server- or client-side, is a performance dog
[18:50:11 CDT(-0500)] <dmccallum54> so yes… every extra bit of data we add to that thing is going to make it a bit slower and hog more server side resources
[18:51:17 CDT(-0500)] <JasonElwood> I'll tell Russ we are getting rid of it. Thanks.
[18:51:23 CDT(-0500)] <dmccallum54> hang on hang on
[18:51:31 CDT(-0500)] <dmccallum54> i just want to register the risk
[18:51:38 CDT(-0500)] <JasonElwood> don't worry. I'll say Jim decided
[18:51:55 CDT(-0500)] <dmccallum54> if js70 is actively working on that particular integration now might not be the right time to start digging in heels
[18:52:21 CDT(-0500)] <dmccallum54> but…. overall…. seems to me that screen is unpleasant for both end users and developers
[18:52:23 CDT(-0500)] <JasonElwood> I agree. getting punchy at this point. I do think we should consider not loading it upon login.
[18:52:34 CDT(-0500)] <dmccallum54> my very own person eyes just glaze over every time it comes up
[18:52:41 CDT(-0500)] <dmccallum54> too. much. information.
[18:52:57 CDT(-0500)] <JasonElwood> and the details tab has twice as much
[18:53:21 CDT(-0500)] <dmccallum54> like… everyone thinks they want a dashboard. they don't. they want a speedometer. and maybe a fuel gauge.