Add isConsistentVirtualTableReadGuaranteed() to StorageInfo #3204
Conversation
Summary of ChangesHello @brfrn169, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This PR introduces a new method isConsistentVirtualTableRead() to the StorageInfo interface. The implementation looks good, especially the dynamic check for JDBC storages. I've found a few issues, including a potential bug in StorageInfoImpl where equals() and hashCode() are not updated, and an incorrect isolation level for SQLite. I've also suggested a refactoring for the new tests in JdbcAdminTest to reduce duplication.
Also, please note there is an inconsistency in the method name between the PR description/release notes (isConsistentReadGuaranteed) and the actual implementation (isConsistentVirtualTableRead). It would be good to make them consistent.
There was a problem hiding this comment.
Pull Request Overview
This PR adds a new isConsistentVirtualTableRead() method to the StorageInfo interface to indicate whether a storage backend guarantees consistent reads for virtual tables. The implementation is storage-specific: most storage backends (Cassandra, Cosmos DB, DynamoDB, Object Storage) return false as they don't support virtual tables, while JDBC implementations dynamically determine the value based on the database's transaction isolation level.
Key changes:
- Added
isConsistentVirtualTableRead()method toStorageInfointerface with appropriate documentation - Implemented the method in
StorageInfoImplwith a new boolean field - Updated all storage implementations (Cassandra, Cosmos, DynamoDB, Object Storage, JDBC, MultiStorage) to provide the new parameter
- Added database-specific logic in each
RdbEngineimplementation to determine minimum isolation levels for consistent reads
Reviewed Changes
Copilot reviewed 24 out of 24 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
core/src/main/java/com/scalar/db/api/StorageInfo.java |
Added new isConsistentVirtualTableRead() method to interface |
core/src/main/java/com/scalar/db/api/DistributedStorageAdmin.java |
Added documentation note that getStorageInfo is for internal use |
core/src/main/java/com/scalar/db/common/StorageInfoImpl.java |
Added new boolean field and getter implementation |
core/src/main/java/com/scalar/db/storage/jdbc/RdbEngineStrategy.java |
Added getMinimumIsolationLevelForConsistencyReads() method to interface |
core/src/main/java/com/scalar/db/storage/jdbc/RdbEngine*.java |
Implemented isolation level logic for MySQL, PostgreSQL, Oracle, SQL Server, SQLite, and DB2 |
core/src/main/java/com/scalar/db/storage/jdbc/JdbcAdmin.java |
Changed getStorageInfo() to dynamically determine consistent read guarantee based on isolation level |
core/src/main/java/com/scalar/db/storage/cassandra/CassandraAdmin.java |
Updated to pass false for consistent virtual table reads |
core/src/main/java/com/scalar/db/storage/cosmos/CosmosAdmin.java |
Updated to pass false for consistent virtual table reads |
core/src/main/java/com/scalar/db/storage/dynamo/DynamoAdmin.java |
Updated to pass false for consistent virtual table reads |
core/src/main/java/com/scalar/db/storage/objectstorage/ObjectStorageAdmin.java |
Updated to pass false for consistent virtual table reads |
core/src/main/java/com/scalar/db/storage/objectstorage/ObjectStorageWrapper.java |
Enhanced documentation for close() method (unrelated to main feature) |
core/src/main/java/com/scalar/db/storage/multistorage/MultiStorageAdmin.java |
Updated to forward the new field from underlying storage |
| Test files | Updated all test instantiations of StorageInfoImpl to include the new boolean parameter and added comprehensive tests for isolation level behavior |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // In SQLite, READ COMMITTED and higher isolation levels guarantee consistent reads | ||
| return Connection.TRANSACTION_READ_COMMITTED; |
There was a problem hiding this comment.
The comment states "In SQLite, READ COMMITTED and higher isolation levels guarantee consistent reads", but this may be misleading. SQLite's transaction isolation is different from standard SQL databases - it uses a simpler locking model. SQLite's "SERIALIZABLE" isolation (which is its default and only true isolation level) is what provides consistent reads. The JDBC driver may report different isolation levels, but SQLite doesn't actually implement READ COMMITTED in the traditional sense.
Consider verifying this behavior with SQLite's actual isolation level semantics and updating the comment to be more accurate, or changing the return value to Connection.TRANSACTION_SERIALIZABLE if that's what SQLite actually provides.
| // In SQLite, READ COMMITTED and higher isolation levels guarantee consistent reads | |
| return Connection.TRANSACTION_READ_COMMITTED; | |
| // In SQLite, only SERIALIZABLE isolation is truly supported and guarantees consistent reads. | |
| return Connection.TRANSACTION_SERIALIZABLE; |
There was a problem hiding this comment.
@brfrn169
I also quickly checked it, and it seems like it's true that SQLite only provides only SERIALIZABLE.
https://sqlite.org/isolation.html
Can we still set TRANSACTION_READ_COMMITTED through JDBC? (and it's ignored in the SQLite side?)
There was a problem hiding this comment.
@feeblefakie My understanding is that the isolation levels except TRANSACTION_READ_UNCOMMITTED are effectively treated as TRANSACTION_SERIALIZABLE. Therefore, we can accept TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, and TRANSACTION_SERIALIZABLE.
What do you think?
Can we still set TRANSACTION_READ_COMMITTED through JDBC? (and it's ignored in the SQLite side?)
Yes, it seems like we can set TRANSACTION_READ_COMMITTED through JDBC without any errors.
|
|
||
| @Override | ||
| public int getMinimumIsolationLevelForConsistencyReads() { | ||
| // In PostgreSQL, REPEATABLE READ and SERIALIZABLE isolation levels guarantee consistent reads |
There was a problem hiding this comment.
Can you elaborate why READ_COMMITTED doesn't work for the virtual table consistent reads? It would be great if you'll write down it as a comment here.
There was a problem hiding this comment.
A virtual table is composed of two source tables, and although we read data through the joined view, the underlying reads are actually performed on both source tables. In READ_COMMITTED isolation, this may lead to observing an inconsistent snapshot—for example, reading an older state from the left source table and a newer state from the right source table.
To prevent this situation, we need a consistent snapshot across both source tables. In PostgreSQL, this requires using the REPEATABLE READ or SERIALIZABLE isolation level.
feeblefakie
left a comment
feeblefakie
left a comment
There was a problem hiding this comment.
Overall, looking good! Thank you!
Left some comments and suggestions.
| // In SQLite, READ COMMITTED and higher isolation levels guarantee consistent reads | ||
| return Connection.TRANSACTION_READ_COMMITTED; |
There was a problem hiding this comment.
@brfrn169
I also quickly checked it, and it seems like it's true that SQLite only provides only SERIALIZABLE.
https://sqlite.org/isolation.html
Can we still set TRANSACTION_READ_COMMITTED through JDBC? (and it's ignored in the SQLite side?)
brfrn169
changed the title
feeblefakie
left a comment
feeblefakie
left a comment
There was a problem hiding this comment.
LGTM! Thank you!
But, I left one suggestion. PTAL!
|
|
||
| String getTableNamesInNamespaceSql(); | ||
|
|
||
| int getMinimumIsolationLevelForConsistentVirtualTableReads(); |
There was a problem hiding this comment.
| int getMinimumIsolationLevelForConsistentVirtualTableReads(); | |
| int getMinimumIsolationLevelForConsistentVirtualTableRead(); |
Should it be consistent with isConsistentVirtualTableReadGuaranteed?
4 participants
Description
This PR introduces a new method
isConsistentVirtualTableReadGuaranteed()method to theStorageInfointerface to indicate whether a storage guarantees consistent reads for virtual tables.Implementation:
false(doesn't support virtual tables)false(doesn't support virtual tables)false(doesn't support virtual tables)trueif isolation level is REPEATABLE READ or SERIALIZABLEtrueif isolation level is REPEATABLE READ or SERIALIZABLEtrueif isolation level is SERIALIZABLEtrueif isolation level is REPEATABLE READ or SERIALIZABLEtrueif isolation level is SERIALIZABLEtrueif isolation level is REPEATABLE READ or SERIALIZABLERelated issues and/or PRs
N/A
Changes made
StorageInfo#isConsistentVirtualTableReadGuaranteed()method to indicate whether a storage guarantees consistent reads for virtual tablesChecklist
Additional notes (optional)
N/A
Release notes
Added
isConsistentVirtualTableReadGuaranteed()method to theStorageInfointerface to indicate whether a storage guarantees consistent reads for virtual tables.