Activity for Fred Toussi
-
Fred Toussi posted a comment on ticket #1744
Please write a simple SQL query showing the issue. Your test is dependent on templates and needs to be dissected.
-
The next point release, date not yet determined.
-
Please test without connection pool. I will check this before the next release and if there is a regression it will be fixed.
-
Most properties are applied to a new database at the time of creation. Make sure the database files do not exist.
-
The cache size prop must be in kilobytes, in this case 128000.
-
JDBCSQLXML fails to compile with JDK 26+
-
Thanks for reporting. I agree with your suggestion. This will be applied to SVN.
-
Thanks for your interest. HSQLDB is supported by OSS-Fuzz. You are welcome to run assessments and report via OSS-Fuzz bug report system and coordinate disclosure with us via email.
-
Thanks for reporting. I think this occurs only with ON DUPLICATE KEY UPDATE. It will be fixed in the next point release. I will post here when it is committed and you can then compile the jar and test with you app.
-
Warning with JAVA 24 / 25 - Call to deprecated method
-
Thanks for reporting. It will be fixed for the next release.
-
Thank you. I will check this later.
-
It all depends on multiple factors, including the transaction model, how you use database connections and when you commit. Each thread must always use a separate connection to write to the database. In the default LOCKS mode, if multiple threads write to the same table, then the first thread's connection needs to be committed before any other thread can write. In the MVCC mode multiple connections can generally write without committing so long as there is no conflict.
-
Reused statement invalidated
-
Thanks for reporting. Please note there have been a lot of changes since version 2.5.2. Please check with version 2.7.4 (either Java 8 or Java 11 jar).
-
Thanks for reporting. Will check it later.
-
Regression in 2.7.4 with respect to auto-generated keys in prepared statements
-
Thanks for reporting. This issue has already been fixed and committed to SVN for the next release, which will happen after Java 25.
-
For future reference, it's good to know where there are no checks. Still, literals such as DATE 'BC 0001-01-01 00:00:00' are not allowed
-
Fix committed to SVN.
-
core code updates - fix for bug #1736 eliminate caught exception (Julian Hyde)
-
Can't retrieve temporals in BC era
-
Hi Christian, For dates (and timestamps) I followed the SQL Standard which allows 0001 to 9999 for the year and does not allow BCE values. This is enforced in date-time literals which do not allow BCE values. When using assignments via Java PreparedStatement etc. and arithmetics involving INTERVAL there is no range checking.
-
You probably missed this: http://www.hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#src_jrt_access_control
-
You asked: What about the OFFSET clause? The PK index is used but there is no quick way to skip to the first row. The reason being there may be gaps in the PK sequence. The rows are retrieved from the PK index and 80000 rows are discarded.
-
You can drop the index and try a WHERE clause with both columns. It should still be fast when the PK index is used.
-
I checked with the released jar and it shows the same result as yours. If you have to keep the useless index, you can fix the query speed by adding he timestamp column to the ORDER BY: explain plan for SELECT id FROM test where id<80000 ORDER BY id, date_sent limit 25 ;
-
I checked in IDE in case there was a bug and ran DatabaseManagerSwing. The main thing is the composite index is not useful for anything. It has exactly the same order as the PK because its first column is the PK column. Your result of EXPLAIN PLAN means the index is used and it should not be slower than using the PK.
-
We don't use this as our base compatibility is Java 1.8. HSQLDB supports logging. What do you want to use this interface for?
-
I checked your test and the correct index is used. The query runs in 0.2 ms for 10000 rows. EXPLAIN PLAN shows this: PLAN --------------------------------------------------- isDistinctSelect=[false] isGrouped=[false] isAggregated=[false] columns=[ COLUMN: PUBLIC.NEWS.ID not nullable ] [range variable 1 join type=INNER table=NEWS cardinality=10000 access=INDEX PRED join condition = [index=SYS_PK_10102 start conditions=[ NOT arg_left=[ IS NULL arg_left=[ COLUMN: PUBLIC.NEWS.ID ]]] end condition=[ SMALLER...
-
DatabaseMetaData.getTablePrivileges dont follow JDBC
-
Thanks. Will fix for next release.
-
JavaSystem should not throw NumberFormatException during normal operation
-
Thanks. Will apply to the next release.
-
Ticket moved from /p/hsqldb/feature-requests/375/
-
build updates
-
documentation updates
-
java doc revision updates
-
JVM-level deadlock
-
Issue found by static code analysis. Fixed and committed to SVN for the next release.
-
core code updates - fix for bug #1730 deadlock
-
core code updates - fix for bug #1712 support getMetaData to return generated keys meta in DML PreparedStatement for DML
-
PreparedStatement.getMetadata() returns null for generated keys mode
-
Support added for PreparedStatement.getMetaData() for next release.
-
core code updates - fix for bug #1712 support getMetaData to return generated keys meta in DML PreparedStatement for DML
-
PreparedStatement.setTimestamp ignores Calendar timezone
-
Fixed and committed to SVN for the next release.
-
core code updates - fix for bug #1729 timestamps
-
Default UUID values corrupt script file
-
Thanks for reporting. Fixed and committed to SVN for the next release.
-
core code updates - fix for bug #1732 Default UUID values
-
Support for date - integer in PostgreSQL mode
-
Thanks for reporting. Support for this has been committed to SVN for the next release.
-
added support for adding / subtracting numbers to / from dates in PostgreSQL compatibility mode
-
The issue here is that HSQLDB does not support queries with joined tables as updatable. Another issue is that the FOR UPDATE clause is accepted and ignored even when the query is not updatable. The following types of query are updatable select * from books b where book_name = 'A BOOK' for update select * from books b where id in (select book_fk from book_tags) for update In the second query, the table books has a write lock and the table book_tags has a read lock.
-
The FOR UPDATE clause is actually ignored in a joined query. The query is read-only, with read locks on the two tables. In my second example query, the query is updatable and there is also a read lock on book_tags. In the default READ COMMITTED isolation mode these read locks are immediately removed after each execution. But in SERIALIZABLE (and REPEATABLE READ) isolation mode the read locks are retained until commit or rollback. So a DELETE statement will be blocked.
-
The FOR UPDATE clause is actually ignored in a joined query. The query is read-only, with read locks on the two tables. In my second example query, the query is updatable and there is also a read lock on book_tabs. In the default READ COMMITTED isolation mode these read locks are immediately removed after each execution. But in SERIALIZABLE (and REPEATABLE READ) isolation mode the read locks are retained until commit or rollback. So a DELETE statement will be blocked.
-
The issue here is that HSQLDB does not support queries with joined tables as updatable. Another issue is that the FOR UPDATE clause is accepted and ignored even when the query is not updatable. The following types of query are updatable select * from books b where book_name = 'A BOOK' for update select * from books b where id in (select book_fk from book_tags) for update In the second query, the table books has a write lock and the table book_fk has a read lock.
-
I will check the FOR UPDATE behavior next week and will also provide more information on the limitations. Re explicit locking, see the same chapter of the guide under < lock table statement >. It goes like LOCK TABLE books WRITE, book_tags READ For current isolation level use the java.sql.Connection method, getTransactionIsolation() For database transaction control, use the query below: select property_value from information_schema.system_properties where property_name = 'hsqldb.tx' Thanks Steve...
-
General locking behavior depends on the transaction control setting for the database (LOCKS or MVCC). Please state which one is being used. I will check the issue in detail in a couple of days.
-
The deleteOnExit hook is used for the .lck file. For your use case, you need to ensure the HSQLDB file names are always distinct from one another. In this situation there is no need for the .lck file, whose function is to prevent two different Java processes from opening the same file-based database. Create the databases with hsqldb.lock_file=false on the database URL. See http://www.hsqldb.org/doc/2.0/guide/dbproperties-chapt.html
-
The deleteOnExit hook is used for the .lck file. For your use case, you need to ensure the HSQLDB file names are always distinct from one another. In this situation there is no need for the .lck file, whose function is to prevent to different Java processes to open the same file-based database. Create the databases with hsqldb.lock_file=false on the database URL. See http://www.hsqldb.org/doc/2.0/guide/dbproperties-chapt.html
-
The deleteOnExit hook is used for the .lk file. For your use case, you need to ensure the HSQLDB file names are always distinct from one another. In this situation there is no need for the .lck file, whose function is to prevent to different Java processes to open the same file-based database. Create the databases with hsqldb.lock_file=false on the database URL. See http://www.hsqldb.org/doc/2.0/guide/dbproperties-chapt.html
-
Try changing the configuration of your connection pool to keep a connection to the database open and to avoid having to close and open the last connection to the database.
-
table named 'group' is causing problems, quoting does not help
-
Server and in-memory mode behave exactly the same in case conversion and retention. If you create a table with a name that is not double quoted, the name is converted to all uppercase. It looks like your various methods of creating tables are not doing exactly the same thing.
-
First you need to find out exactly what the table name is. You can do this with a SELECT from the INFORMATION_SCHEMA.TABLES. Supposing the actual name of the table is GROUP (all uppercase), you should be able to use alter table "GROUP" rename to groups
-
The type DOUBLE is for floating point values which are stored in an approximate fashion. Use a DECIMAL type such as DECIMAL(16,2) to store exact monetary values. The DECIMAL(16,2) can be used for currencies such as the Dollar or Euro for values over many trillion units.
-
Compairing 0's values not working as expacted!
-
The type DOUBLE is for floating point values which are stored in an approximate fasion. Use a DECIMAL type such as DECIMAL(16,2) to store exact monetary values. The DECIMAL(16,2) can be used for currencies such as the Dollar or Euro for values over many trillion units.
-
Thanks for reporting. I will investigate this later this year. You can eliminate this by turning off the auto checkpoint which is done by the HSQLDB Timer thread. Set hsqldb.log_size=0 as a connection property.
-
Please note "org.hsqldb.jdbc.JDBCDriver" is the JDBC driver class, while "org.hsqldb.jdbcDriver" is the old class name. The old class name is still supported for backward compatibility.
-
Ideally, conversions should be symmetrical. I will include this issue in a future review of JDBC compatibility.
-
Hi Dick, I don't know anything about this issue. It would be better to ask in a Tomcat forum. I know Tomee's latest release has an hsqldb 2.7.4 dependency (https://tomee.apache.org/10.0.0/release-notes.html) so you could also check there.
-
This is probably working fine. The "SELECT ? FROM table1" has a parameter with undefined data type, which is defaulted to CHARACTER. After that, you cannot expect retrieved values to match inserted values, as different conversions to / from character is performed. If you want to explore this further, try this "SELECT CAST(? AS TIMESTAMP WITH TIME ZONE) FROM table1" instead.
-
We have not tested with recent releases of log4j and have not modified access to log4j in 2.7.4. Please find out from which version of log4j the error appears.
-
Union of DECIMAL and INTEGER in subqueries throws general error
-
Thanks for reporting. You need to cast one or both of the column references for this type of query to work. This may be fixed in a future version.
-
core code updates - move HsqlException class to org.hsqldb.error package
-
I noticed that t is empty and joining it with the VALUES(1) results in an empty result regardless of ON FALSE or ON TRUE. But there is a row in VALUES(1) that is not joined with t and it looks like WHEN NOT MATCHED means this row should be inserted. I need to check the Standard text again before deciding.
-
Thanks for reporting. I need to check the expected behaviour according to SQL:2023 before commenting.
-
core code updates - move HsqlException class to org.hsqldb.error package
-
Please provide the complete query and the complete error message.
-
Support FUNCTION RETURNS ... ARRAY for Java functions
-
Thanks for reporting. Fixed and committed to SVN. A usage example is in SVN /base/trunk/src/org/hsqldb/test/TestRoutines.java Please build the jar and test and report the result.
-
test updates - fix for bug #1726
-
core code updates - fix for bug #1726
-
test code updates
-
core code updates - move HsqlException class to org.hsqldb.error package
-
core code updates - move HsqlException class to org.hsqldb.error package
-
core code updates - move HsqlException class to org.hsqldb.error package
-
You can indicate the intended type using a CAST: USING (select ? AS ID, CAST(? AS DATE) AS DATE1, CAST(? AS TIMESTAMP) AS TIMESTAMP1, We may support setting the date and timestamp without a parameter cast in the next release.
-
Accessing generated values, where non exists throws exception on second try.
-
Thanks again. Fixed and committed to SVN /base/trunk/
-
General error when comparing VARCHAR value with CLOB value
-
Fixed and committed.
-
core code updates - fix for bug #1723
-
core code updates - fix for bug #1725
-
I have checked this but cannot see the issue. Please attach your .java test file to this bug report.
-
This will have a high priority for a new bug fix release early next year.
1 >
