[11:44:12 CDT(-0500)] <dmccallum54> restarting linux ci
[12:38:56 CDT(-0500)] <TonyUnicon> Jason, the first round of fixes I spoke about in the meeting are checked in
[12:39:03 CDT(-0500)] <TonyUnicon> including addressing the N+1 problem
[12:39:26 CDT(-0500)] <JasonElwood> sweet. thanks
[12:39:53 CDT(-0500)] <JasonElwood> building Linux CI
[14:32:18 CDT(-0500)] <tbain> Working on SSP-995, are you supposed to be able to select multiple service reasons, or should you only be able to select 1?
[14:33:51 CDT(-0500)] <JasonElwood> 0 to all
[14:36:01 CDT(-0500)] <tbain> Okay, thaks
[14:36:03 CDT(-0500)] <tbain> thanks*
[15:20:31 CDT(-0500)] <JasonElwood> Paul- what is the expected value of the student_type_code in external_person? Is it the student_type.id or student_type.name?
[15:23:17 CDT(-0500)] <JasonElwood> In either case, external_person.student_type_code is varchar(10) and uuid is much larger and student_type.name is varchar(80). Am I missing something, or should this be adjusted?
[15:26:28 CDT(-0500)] <pspaude> Typicaly the 3 letter value used in the SSP application already. However, it can be different than the student_type.name. In my commits today, there will be a student_type.code column.
[15:26:55 CDT(-0500)] <pspaude> It took a long time due to MSSQL issues with the liquibase scripts, but with help from Dan we got it all worked out.
[15:27:24 CDT(-0500)] <pspaude> I can commit the liquibase stuff now if you want.
[15:27:57 CDT(-0500)] <pspaude> Although, I think Dan still has the background services turned off.
[15:28:44 CDT(-0500)] <dmccallum54> external_person.student_type_code -> student_type.code
[15:29:00 CDT(-0500)] <dmccallum54> this is how all new external->internal "references" should work
[15:29:38 CDT(-0500)] <dmccallum54> b/c it decouples the reference from both the internal db primary key and the on-screen display value
[15:30:02 CDT(-0500)] <dmccallum54> external data should not know about internal PKs
[15:30:17 CDT(-0500)] <dmccallum54> and on-screen display values should be editable w/o breaking the integration
[15:30:33 CDT(-0500)] <JasonElwood> oh yeah, missed that column at the end. should be fine then
[15:39:09 CDT(-0500)] <pspaude> Hey dan, is there anyway to ignore a changeset? Archna has a changeset issue wehre external person the student_type_code already exists. I'm trying to reply, but I"m thinking if she drops the column the view will have to go too and she will have to redo it. Is there any other way?
[15:40:41 CDT(-0500)] <TonyUnicon> im walking her through it
[15:40:42 CDT(-0500)] <pspaude> Hey thanks Tony. I forgot that is how I did it awhile back.
[15:41:09 CDT(-0500)] <TonyUnicon> yeah, in reality there should be a precondition to check if the column exists before it tries to drop it, ive been stuck in this trap myself
[15:41:33 CDT(-0500)] <pspaude> I believe dan said no on the precondition, but you'd have to check with him.
[15:41:41 CDT(-0500)] <TonyUnicon> oh?
[15:42:27 CDT(-0500)] <pspaude> Something that it doesn't work properly and would be nice otherwise.
[15:42:58 CDT(-0500)] <dmccallum54> why would the column have ended up in there in the 1st place?
[15:43:03 CDT(-0500)] <dmccallum54> for a real deployment
[15:43:13 CDT(-0500)] <TonyUnicon> well he had moved the script
[15:43:22 CDT(-0500)] <TonyUnicon> to the integration changesets
[15:43:30 CDT(-0500)] <TonyUnicon> so for folks who ran the old one
[15:43:36 CDT(-0500)] <TonyUnicon> they will be stuck in that state
[15:43:39 CDT(-0500)] <TonyUnicon> but for new envs
[15:43:44 CDT(-0500)] <TonyUnicon> I believe it wouldn't be an issue
[15:44:01 CDT(-0500)] <dmccallum54> if it's just happening b/c of a transient bug that only affects devs i voted to keep the changeset/s simple and let devs delete the column themselves if they already had it. b/c we're experts. right.
[15:44:56 CDT(-0500)] <tbain> hear hear!
[15:45:01 CDT(-0500)] <pspaude> Can we get some quotes around "experts" 
[15:47:21 CDT(-0500)] <js70> 4 years ago I couldn't spell developer now I are one.
[15:47:55 CDT(-0500)] <TonyUnicon> lol