- 15 3月, 2017 1 次提交
-
-
由 Max Englander 提交于
-
- 19 2月, 2017 1 次提交
-
-
由 Max Englander 提交于
-
- 18 2月, 2017 1 次提交
-
-
由 Max Englander 提交于
-
- 13 2月, 2017 1 次提交
-
-
由 Max Englander 提交于
-
- 12 2月, 2017 1 次提交
-
-
由 Max Englander 提交于
-
- 09 2月, 2017 2 次提交
-
-
由 Noel Grandin 提交于
-
由 Noel Grandin 提交于
to make it more obvious
-
- 06 2月, 2017 2 次提交
-
-
由 Noel Grandin 提交于
Updated commercial support information
-
由 Steve McLeod 提交于
-
- 02 2月, 2017 1 次提交
-
-
由 Noel Grandin 提交于
Use System.nanoTime() to check timeouts
-
- 30 1月, 2017 1 次提交
-
-
由 Ulrich Wielant 提交于
-
- 26 1月, 2017 1 次提交
-
-
由 Ulrich Wielant 提交于
System.currentTimeMillis() is influenced by system time corrections whereas System.nanoTime() is strongly sequential. So it is better to use System.nanoTime() when checking for timeouts and elapsed time.
-
- 23 1月, 2017 1 次提交
-
-
由 Noel Grandin 提交于
-
- 22 1月, 2017 1 次提交
-
-
由 Noel Grandin 提交于
Fix JDBC type of TIMESTAMP WITH TIME ZONE
-
- 21 1月, 2017 1 次提交
-
-
由 Noel Grandin 提交于
-
- 20 1月, 2017 7 次提交
-
-
由 alexpaschenko 提交于
* Added WITH to CREATE SCHEMA to supply default TableEngine params * Updated docs to reflect changes in CREATE SCHEMA * Review fixes - docs; code de-duplication; test for table engine params in schema * Setter for table engine params in Schema
-
由 Noel Grandin 提交于
-
由 Sergi 提交于
-
-
由 Sergi 提交于
-
由 Noel Grandin 提交于
Optimized column vs constant comparisons
-
由 Alexander Paschenko 提交于
-
- 19 1月, 2017 4 次提交
-
-
由 Philippe Marschall 提交于
Currently the JDBC type of TIMESTAMP WITH TIME ZONE is Types.OTHER. JDBC 4.2 has a dedicated type for this Types.TIMESTAMP_WITH_TIMEZONE. Unfortunately this type is only available in JDBC 4.2/Java 1.8 so I hard code the constant value instead of the constant reference.
-
由 Noel Grandin 提交于
unfortunately I had to hit it with the big synchronization stick. I could no simple way to rescue the current rather clever code. This bug was reported by Anatolii K in this message: https://groups.google.com/d/msg/h2-database/rhSoRhzeZzk/gc-pNlSpEwAJ
-
由 Noel Grandin 提交于
Issue #434 - parse engine params in CREATE TABLE w/o engine specified
-
由 Noel Grandin 提交于
Add target to gitignore
-
- 18 1月, 2017 3 次提交
-
-
由 Philippe Marschall 提交于
Currently the target/ folder is not in .gitignore this gives me changes when I compile the source.
-
由 Alexander Paschenko 提交于
-
由 Noel Grandin 提交于
we don't seem to be keeping this up to date anymore
-
- 17 1月, 2017 5 次提交
-
-
由 Alexander Paschenko 提交于
-
由 Noel Grandin 提交于
-
由 Noel Grandin 提交于
-
由 Noel Grandin 提交于
# Conflicts: # h2/src/docsrc/html/changelog.html
-
由 Noel Grandin 提交于
-
- 16 1月, 2017 2 次提交
-
-
由 Philippe Marschall 提交于
Some typos snuck into debug log messages causing a wrong class name to be logged.
-
由 Noel Grandin 提交于
Update Changelog
-
- 15 1月, 2017 1 次提交
-
-
由 Philippe Marschall 提交于
Some PRs merged into 1.4.193 and 1.4.194 are missing from the changelog.
-
- 13 1月, 2017 1 次提交
-
-
由 Noel Grandin 提交于
-
- 12 1月, 2017 2 次提交
-
-
由 Philippe Marschall 提交于
Currently java.sql.Array is only supported when returned from the database. Passing arrays to the database is not supported. Connection#createArrayOf, PreparedStatement#setArray and PreparedStatement#setObject with a java.sql.Array are not supported. This pull requests implements passing java.sql.Array objects to the database and includes the following changes: - implement Connection#createArrayOf - implement PreparedStatement#setArray - implement array support in ResultSet#getObject - implement conversion from java.sql.Array to Value - update DataType#convertTo to support arrays as well - add tests for #createArrayOf, #setArray and #setObject - add tests for #getObject with an array argument - remove the test for Connection#createArrayOf being unsupported - remove the test for PreparedStatement#setArray being unsupported The typeName passed to #createArrayOf is ignored, this is in accordance with JdbcArray#getBaseTypeName returning "NULL" and JdbcArray#getBaseType returning Types.NULL even if the backing array is homogeneous.
-
由 Noel Grandin 提交于
-