jasig-ssp IRC Logs-2013-03-25
[11:52:38 CDT(-0500)] <dmccallum54> does anything in 1.2.0 actually use v_/external_course_section
[11:52:45 CDT(-0500)] <dmccallum54> i see all the associated Java machinery
[11:52:50 CDT(-0500)] <dmccallum54> but nothing that actually uses it
[11:54:29 CDT(-0500)] <dmccallum54> i.e. there is no API for it, i don't see its model referenced by another API's model, and I don't see any JS models with similar naming
[11:55:22 CDT(-0500)] <JasonElwood> I found that same thing over the weekend. I don't know any use in 1.2
[11:56:50 CDT(-0500)] <dmccallum54> ok. will open a ticket to kill it
[11:57:12 CDT(-0500)] <JasonElwood> it may be used in 2.0. let me check real quick
[11:59:16 CDT(-0500)] <TonyUnicon> I would imagine MAP would use a table like that
[12:00:44 CDT(-0500)] <JasonElwood> it looks like all the values in the 1.2 version exist in external_student_transcript_course
[12:01:01 CDT(-0500)] <dmccallum54> https://issues.jasig.org/browse/SSP-882
[15:02:03 CDT(-0500)] <dmccallum541> anybody lose any sleep if i delete this 2G catalina.out on our linux CI host?
[15:03:48 CDT(-0500)] <JasonElwood> nope. I'll even be happy if you tell me it's on the ephemeral and working as expected before you delete it
[15:05:25 CDT(-0500)] <dmccallum541> well then. be happy.
[15:05:50 CDT(-0500)] <dmccallum541> i will even go so far as to set up rotation so the JVM doesn't bomb out the next time the file hits 2G
[15:07:56 CDT(-0500)] <TonyUnicon> 2 gig text file. sweet fancy moses
[15:08:17 CDT(-0500)] <dmccallum541> wow. having hibernate logging at DEBUG does not lead to a faster overall user experience
[15:08:23 CDT(-0500)] <JasonElwood> kinda big. just one day?
[15:08:37 CDT(-0500)] <TonyUnicon> hibernate spits out so much junk
[15:08:55 CDT(-0500)] <dmccallum541> to be fair… we feed it a lot of junk
[15:09:34 CDT(-0500)] <dmccallum541> alright. confirmed /media/ephemeral0/tomcat/logs/catalina.out is working. deleting /var/log/tomcat6/catalina.out
[15:09:46 CDT(-0500)] <TonyUnicon> yeah it can't help but but be verbose but I cringe when I know I need to wade through hibernate logs
[15:09:47 CDT(-0500)] <js70> thats nothing with reports I was running out of space after a few hours 200+ gigs. good times.
[15:13:53 CDT(-0500)] <TonyUnicon> jim always bragging about his big logs
[15:16:07 CDT(-0500)] <dmccallum541> alas jim has /topic turned off for this channel
[15:16:23 CDT(-0500)] <js70> :^)
[15:30:22 CDT(-0500)] <JasonElwood> Just re-opened 875. It could be 882 but the db changes failed. stack is on the issue.
[15:31:38 CDT(-0500)] <dmccallum541> restarting linux ci again
[15:45:35 CDT(-0500)] <dmccallum541> aaaaaand again
[15:46:09 CDT(-0500)] <JasonElwood> no worries. I'm not sure anybody is using it right now
[15:46:31 CDT(-0500)] <js70> k take a look.
[15:52:47 CDT(-0500)] <js70> hey, jason, make sure you have the latest, I checked in some code that you are missing. Also, you need to remove the checksum for i00009xml and i0000010.xml
[15:55:29 CDT(-0500)] <JasonElwood> two new commits, just sync'd them down
[15:57:39 CDT(-0500)] <JasonElwood> still an error with i000009.xml. are you saying that file needs to be removed?
[15:58:36 CDT(-0500)] <js70> no,you need to remove the references to i000009.xml in the databasechangelog
[16:04:58 CDT(-0500)] <JasonElwood> that ran. checking the results
[16:05:04 CDT(-0500)] <js70> k
[16:08:20 CDT(-0500)] <JasonElwood> 875 looks good. the two column changes are present
[16:10:59 CDT(-0500)] <JasonElwood> 882 is marked resolved and there's a commit. however, the external_course_section table still exists
[17:11:49 CDT(-0500)] <JasonElwood> JS- did you get my message about 882?
[17:18:16 CDT(-0500)] <JasonElwood> it appears the commit for 882 included i000011.xml for the changeset. That changeset drops external_students_by_course which was handled in 857. 882 should drop external_course_section
[17:30:41 CDT(-0500)] <js70> just a sec. been buried in 818{color}
[17:32:34 CDT(-0500)] <JasonElwood> np
[17:35:28 CDT(-0500)] <dmccallum541> quick survey....
[17:35:53 CDT(-0500)] <dmccallum541> trying to decide where to put Tyler's data migration tool in source control
[17:36:21 CDT(-0500)] <dmccallum541> it's written in groovy but it's factored into a number of java-style classes
[17:37:22 CDT(-0500)] <dmccallum541> so it's not entirely trivial. and running it is a bit more involved than some of the other scripts we already have in ./scripts
[17:37:36 CDT(-0500)] <tbain> That or I could take the time to try and re-write it so it doesn't entail such heftyness
[17:38:12 CDT(-0500)] <dmccallum541> to develop on it, you want IDE support, which you can do in IntelliJ, for example, by just adding another content root. but then you get the compiled result included in output dirs, which isnt really what you want
[17:38:42 CDT(-0500)] <dmccallum541> so i'm leaning toward just throwing this into an all-new Jasig repo
[17:39:07 CDT(-0500)] <dmccallum541> so it's easier to interact with on its own terms and patch independently of larger SSP dev efforts
[17:39:46 CDT(-0500)] <dmccallum541> worth pointing out that Tyler has nicely externalized SSP version-specific details like the metadata for the schema relations that it will attempt to migrate
[17:41:10 CDT(-0500)] <dmccallum541> so… do people have an opinion on whether a separate repo would actually make their life more difficult in terms of Now Having Yet One More Thing To Keep Track Of, or would the separation fit better with your preferred workflow when dealing with non-trivial groovy programs
[17:42:29 CDT(-0500)] <dmccallum541> tbain thanks for the offer… i dont think a refactor is called for. imho, the ability to evolve the scripts independently of the larger SSP codebase is actually the bigger issue as compared to the complexity of the execution command
[17:57:32 CDT(-0500)] <js70> No strong opinion. If it lets the world evolve more easiliy, I am in favor of the seperate repo option.
[18:28:07 CDT(-0500)] <js70> https://issues.jasig.org/browse/SSP-882 should be complete now.
[18:28:27 CDT(-0500)] <JasonElwood> I'll test it out. thanks
[18:50:42 CDT(-0500)] <JasonElwood> should 000009.xml still be commented out?
[18:50:54 CDT(-0500)] <JasonElwood> 000024.xml failed. the JE html stripping
[18:58:05 CDT(-0500)] <js70> hmm. je html stripping failed because you probably don't have the orginal html.
[18:58:08 CDT(-0500)] <js70> it worked for me.
[18:58:37 CDT(-0500)] <js70> can you send me the html you have in the database?
[18:58:56 CDT(-0500)] <js70> and 00009.xml should not be commented out.
[18:59:19 CDT(-0500)] <JasonElwood> Dan- 857 checks out now. Jim made two additional commits today. You cherry-picked the code for master before the last 3 commits it appears.
[18:59:25 CDT(-0500)] <js70> you mean i000009.xml correct?
[19:00:41 CDT(-0500)] <JasonElwood> I do not have the original html in the database. I have the template that I provided to use, as I used it for testing.
[19:01:45 CDT(-0500)] <dmccallum541> JasonElwood ok I'll merge the rest of 857 into master
[19:01:58 CDT(-0500)] <JasonElwood> but, the application shouldn't fail because the changeset didn't complete. there may be adopters that modified the template with or without html.
[19:02:02 CDT(-0500)] <JasonElwood> 875
[19:02:06 CDT(-0500)] <JasonElwood> just to be clear
[19:02:17 CDT(-0500)] <dmccallum541> yep
[19:02:19 CDT(-0500)] <JasonElwood> Js- I do mean i000009.xml
[19:03:07 CDT(-0500)] <js70> k. we talking about 1.2 or 2.0 its not commented out from what I can see in 1.2
[19:04:24 CDT(-0500)] <js70> you are correct that it should not fail with changes. it just should not do an update. do you have the error log?
[19:04:29 CDT(-0500)] <JasonElwood> talking about 1.2. you previously told me to remove it from the changelog. I did before the 882 commit. the deployment worked. after I sync'd the new code i000009.xml was in play again, and it failed
[19:04:58 CDT(-0500)] <JasonElwood> let me get a clean build and log. one sec
[19:05:05 CDT(-0500)] <js70> k
[19:07:10 CDT(-0500)] <js70> made changes in i000009.xml for SSP-875 Fixed dropNotNullConstraints
[19:07:28 CDT(-0500)] <js70> this would cause the same issues with the checksum.
[19:07:37 CDT(-0500)] <JasonElwood> deploying now
[19:07:41 CDT(-0500)] <js70> k
[19:09:51 CDT(-0500)] <JasonElwood> emailed stack
[19:10:36 CDT(-0500)] <js70> thks
[19:12:01 CDT(-0500)] <js70> checksums have changed for org/jasig/ssp/database/changesets/000024.xml and org/jasig/ssp/database/integrationchangesets/i000009.xm
[19:12:55 CDT(-0500)] <js70> the first because the orginal would overwrite no matter what was in the Early Alert Journal note and the second because i had messed up the dropNotNullConstraints.
[19:13:15 CDT(-0500)] <js70> you will need to remove those entries from your databaselog.
[19:13:57 CDT(-0500)] <js70> should work fine after that.
[19:21:34 CDT(-0500)] <js70> confirming...
[19:22:02 CDT(-0500)] <JasonElwood> dude. it ran this time but dropped three tables it shouldn't have.
[19:22:24 CDT(-0500)] <js70> wha!
[19:22:28 CDT(-0500)] <js70> what!
[19:22:36 CDT(-0500)] <JasonElwood> just kidding. it worked. thanks for fixing it.
[19:22:51 CDT(-0500)] <js70> NOT FUNNY!!!:^)
[19:23:08 CDT(-0500)] <JasonElwood> I know. I needed a little laugh after a rough day.
[19:23:49 CDT(-0500)] <js70> you are my hero. no way i could do what you do.
[19:24:45 CDT(-0500)] <JasonElwood> i couldn't do any of it if you guys didn't do a good job already
[19:27:21 CDT(-0500)] <js70> last week has felt like running with sissors in a sandbox.
[19:27:42 CDT(-0500)] <JasonElwood> it's been pretty tough
[19:29:01 CDT(-0500)] <js70> good thing 2.0 isn't adding to many new features.:^)
[19:29:20 CDT(-0500)] <JasonElwood> yeah. we have a little more than two weeks before we start this again
[19:30:35 CDT(-0500)] <js70> well, I should probably go home and find out if I'm still married.
[19:30:44 CDT(-0500)] <JasonElwood> definitely
[19:31:04 CDT(-0500)] <JasonElwood> thanks for the help man. everything is checking out so far
[19:41:19 CDT(-0500)] <js70> kool