hsqldb игнорирует первую операцию вставки в таблицу на сервере (сервер должен быть "подогрет"?)

Question

У нас очень любопытная проблема с hsqldb. Мы выполняем некоторые тесты, которые отлично работают на MySQL, но недавно мы перешли на hsqldb для наших модульных тестов. При этом мы заметили, что некоторые наши тесты начали проваливаться. Один из тестов вставляет три записи A, B и C и пытается извлечь первые две, A и B. Однако, только B возвращается при первом запуске теста в только что сконфигурированной (пустой) базе данных. Однако, если мы повторим тест для одной и той же базы данных, будут возвращены и A ', и B' (прежде чем вы спросите, да, A, B и C отличаются от A ', B' и C ').

Мы попытались заставить базу данных сохранить записи, и мы вставили задержки. Ничто не помогает, кроме «прогрева базы данных» с помощью одной вставки. Если после этого мы проверим журналы hsqldb, они содержат все операторы вставки, даже те, которые мы не можем получить с помощью SELECT при первом запуске базы данных.

Кто-нибудь когда-нибудь испытывал проблемы с hsqldb, которые нужно было "подогревать" с помощью фиктивного оператора вставки? Если мы выполним оператор вставки с мусором перед запуском наших тестов, они также успешно завершатся.

Мы тестировали на hsqldb 2.0.0 и 2.1.0. Обе версии дают одинаковый результат.

Answer 1

Реальный ответ дает ОП в одном из комментариев.HSQLDB не игнорирует первую вставку.По умолчанию HSQLDB и MySQL используют 0 и 1 соответственно для первого значения автоинкремента, сгенерированного для столбца идентификаторов в таблице.Запрос OP предполагал, что первым значением было значение MySQL (1).

С HSQLDB GENERATED BY DEFAULT AS IDENTITY START WITH 1 может использоваться для определения столбца автоинкремента, чтобы соответствовать значению MySQL по умолчанию.

Answer 2

Я никогда не использовал hsqldb, но вы пробовали INSERT INTO ...; COMMIT; и затем запускали SELECT ..?

Операция с базой данных (INSERT, UPDATE или DELETE) не является необоснованной задержкой.Это, вероятно, не должно происходить, когда база данных не находится под большой нагрузкой, но вы не можете на это рассчитывать.