[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
[12:25:39 CST(-0600)] <dmccallum54> for the framework tables, i think what they provide are DDL files and we just need to decide how to execute those
[12:26:04 CST(-0600)] <dmccallum54> in the sample app i think they just use the jdbc namespace to execute those DDL files
[12:27:01 CST(-0600)] <dmccallum54> so in my mind, at this point, the question is whether liquibase really buys us anything, or if it's simpler to just go straight DDL for both framework and staging tables
[12:28:15 CST(-0600)] <dmccallum54> because we don't really have a need for "migrations" in any of our custom tables, and SpringBatch doesn't use liquibase for migrations of its framework tables, I'm actually leaning toward just maintaining possible db-specific ddl files in our source, using db-specific tools to generate those files from existing, "known-good" SSP installs
[12:30:13 CST(-0600)] <TonyUnicon> ok
[12:31:19 CST(-0600)] <TonyUnicon> so I'll start with that
[12:31:51 CST(-0600)] <dmccallum54> https://github.com/spring-projects/spring-batch/blob/master/spring-batch-samples/src/main/resources/data-source-context.xml
[12:32:16 CST(-0600)] <dmccallum54> here's what i was referring to with the cryptic comment about the "jdbc namespace"
[12:32:35 CST(-0600)] <dmccallum54> see the "jdbc:initialize-database" element at the tiop?