[11:59:37 CST(-0600)] <TonyUnicon> finally have a sqlserver instance up with ssp data… hooray
[11:59:49 CST(-0600)] <TonyUnicon> and thanks to Jim was able to fire off the prototype, double hooray
[11:59:49 CST(-0600)] <dmccallum54> pretty exciting
[12:00:01 CST(-0600)] <TonyUnicon> "exciting"
[12:01:31 CST(-0600)] <TonyUnicon> also trying out STS with this workspace
[12:07:49 CST(-0600)] <dmccallum54> js70, i mentioned this to Tony yesterday, but forgot to say anything when we were talking… can we please try to stick with spaces instead of tabs and 4-space indents for this project?
[12:08:17 CST(-0600)] <dmccallum54> so we dont end up with the moody, per-file code styling we've got going on in SSP
[12:08:57 CST(-0600)] <dmccallum54> i'm still trying to figure out how to share a single code style definition across IDEA and Eclipse
[12:11:43 CST(-0600)] <dmccallum54> looks like it's going to have to go in the other direction, i.e. define the styles in eclipse, then import into intellij
[12:12:01 CST(-0600)] <dmccallum54> but the main thing now is just to agree on whitespace chars
[12:12:19 CST(-0600)] <TonyUnicon> yeah just changed my eclipse preference to use only spaces for whitespace
[12:12:27 CST(-0600)] <dmccallum54> thx
[12:18:10 CST(-0600)] <TonyUnicon> Dan, do you think it maybe useful to use ssp/liquibase for staging/framework tables
[12:18:34 CST(-0600)] <TonyUnicon> so we get the sql abstraction for free
[12:18:41 CST(-0600)] <dmccallum54> so
[12:20:12 CST(-0600)] <dmccallum54> i had been thinking about that a little bit, but more in the specific context of tests… https://issues.jasig.org/browse/SSP-1865
[12:20:46 CST(-0600)] <dmccallum54> (dont worry about the jira tickets themselves right now, they need to be re-worked to reflect what we're actually doing, and that doesn't need to block any current work)
[12:21:36 CST(-0600)] <js70> yep. will do
[12:22:29 CST(-0600)] <dmccallum54> but my two thoughts were this: 1) we don't necessarily need all the bloody, blow-by-blow liquibase from SSP proper is that's hard to reuse for any reason, and 2) we need to make sure we dont accidentally cause conflict with anything that's going on in SSP's DATABASECHANGELOG* tables
[12:24:07 CST(-0600)] <dmccallum54> so what i was actually thinking was… for our staging tables we really just need to know what version of SSP we're talking about and the DDL that defines staging tables for that version… and we could get that fairly easily by using liquibase to generate changesets given an existing install of whatever version of SSP we're talking about
[12:24:24 CST(-0600)] <dmccallum54> we dont really need "migrations" for these staging tables b/c their contents are totally transient