Use %TABLE_NAME% placeholders in JdbcIndexedSessionRepository schema scripts

[philwebb]

Expected Behavior
Currently schema SQL files shipped in org.springframework.session.jdbc have hard-coded table names despite JdbcIndexedSessionRepository offering a setTableName method.

It would be helpful if the scripts could use %TABLE_NAME% placeholders much like the SQL defined in JdbcIndexedSessionRepository constants. That way the schema could be modified before it's run to generate expected table names.

Current Behavior
Scripts always generate tables with the name or prefix SPRING_SESSION.

Context
See spring-projects/spring-boot#33748 for background.

I'm not sure if changing the SQL will break existing users since they'll need to remember to perform the search and replace. Perhaps a utility method could be provided to take care of this.

[marcusdacoregio]

Hi @philwebb,

it looks like a utility method would be better to avoid breaking existing users that are loading the schema files manually, we can consider using the %TABLE_NAME% placeholder in a future major version.

Would something along these lines work for you?

public class JdbcSchemaUtils {
	
	private final ResourceLoader resourceLoader;

	public JdbcSchemaUtils(ResourceLoader resourceLoader) {
		this.resourceLoader = resourceLoader;
	}

	private String loadSchemaReplacingDefaultTableName(String schema, String tableName) throws IOException {
		Resource resource = this.resourceLoader.getResource(schema);
		try (BufferedReader reader = new BufferedReader(new InputStreamReader(resource.getInputStream()))) {
			String schemaScript = reader.lines().collect(Collectors.joining(""));
			return schemaScript.replace(JdbcIndexedSessionRepository.DEFAULT_TABLE_NAME, tableName);
		}
	}

}

[philwebb]

Yeah, that sounds like a good compromise. It's pretty much the same as the code in spring-projects/spring-boot#33748 (comment), but I feel more comfortable with it being in the spring-session codebase.

At least that way the code that does the replace and the data that it changes are colocated in the same repository and tests can hopefully catch any problems early.