Prior to this commit, utility methods in JdbcTestUtils interpreted SQL
comments as separate statements, resulting in an exception when such a
script is executed.
This commit addresses this issue by introducing a
readScript(lineNumberReader, String) method that accepts a comment
prefix. Comment lines are therefore no longer returned in the parsed
script. Furthermore, the existing readScript(lineNumberReader) method
now delegates to this new readScript() method, supplying "--" as the
default comment prefix.
Issue: SPR-9593
Backport-Commit: 4aaf014cc6
Previously, DatabasePopulatorUtils#execute looked up a Connection from
the given DataSource directly which resulted in the executed statements
not being executed against a transactional connection (if any) which in
turn resulted in the statements executed by the populator potentially
not being rolled back.
Now DataSourceUtils#getConnection is used to transparently take part in
any active transaction and #releaseConnection is used to ensure the
connection is closed if appropriate.
Issue: SPR-9465
Backport-Issue: SPR-9457
Backport-Commit: 49c9a2a915
The username is usually not null, but it could be for some embedded databases.
Always setting generatedKeysColumnNameArraySupported to false when getGeneratedKeysSupported is false, since it can't be supported without having generated keys supported. This change only affects logging messages.
Issue: SPR-9006
Adding a static CustomSQLExceptionTranslatorRegistry and a CustomSQLExceptionTranslatorRegistrar that can be used to register custom SQLExceptionTranslator implementations for specific databases from any application context.
This can be used in application contexts like this:
<bean class="org.springframework.jdbc.support.CustomSQLExceptionTranslatorRegistrar">
<property name="sqlExceptionTranslators">
<map>
<entry key="H2">
<bean class="com.yourcompany.data.CustomSqlExceptionTranslator"/>
</entry>
</map>
</property>
</bean>
Issue: SPR-7675
Prior to this change, single quotes were incorrectly parsed by
NamedParameterUtils#parseSqlStatement, resulting in incorrect parameter
counts:
ParsedSql sql = NamedParameterUtils
.parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
assert sql.getTotalParameterCount() == 0 // incorrect, misses :xxx
That is, presence of the single-quoted string caused the parser to
overlook the named parameter :xxx.
This commit fixes the parsing error such that:
ParsedSql sql = NamedParameterUtils
.parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
assert sql.getTotalParameterCount() == 1 // correct
Issue: SPR-8280
ResourceDatabasePopulator is a component that underlies the database
initialization support within Spring's jdbc: namespace, e.g.:
<jdbc:initialize-database data-source="dataSource">
<jdbc:script execution="INIT" location="classpath:init.sql"/>
</jdbc:initialize-database>
Prior to this commit, ResourceDatabasePopulator#executeSqlScript's use
of Statement#executeUpdate(sql) precluded the possibility of SELECT
statements because returning a result is not permitted by this method
and results in an exception being thrown.
Whether this behavior is a function of the JDBC specification or an
idiosyncracy of certain implementations does not matter as the issue
can be worked around entirely. This commit eliminates use
of #executeUpdate(sql) in favor of #execute(sql) followed by a call
to #getUpdateCount, effectively allowing any kind of SQL statement to
be executed during database initialization.
Issue: SPR-8932
Prior to this change, roughly 5% (~300 out of 6000+) of files under the
source tree had CRLF line endings as opposed to the majority which have
LF endings.
This change normalizes these files to LF for consistency going forward.
Command used:
$ git ls-files | xargs file | grep CRLF | cut -d":" -f1 | xargs dos2unix
Issue: SPR-5608
Spring Buildmaster
Juergen Hoeller
Sam Brannen
Chris Beams
Phillip Webb
Oliver Gierke
Thomas Risberg