#744 Fix table existence checks in QueryExecutorJdbc to use Hive metadata and DESCRIBE TABLE#745
Conversation
…data and DESCRIBE TABLE
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughQueryExecutorJdbc refactors table existence detection with optimization-aware branching: when optimized, it checks Hive metadata via DatabaseMetaData and falls back to DESCRIBE; when unoptimized, it uses a dedicated SQL-based probe. Two new helper methods implement the fallback strategies. Logging levels are adjusted during cleanup, and a test validates the metadata-based detection behavior. ChangesTable existence check optimization and fallback strategies
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
pramen/core/src/main/scala/za/co/absa/pramen/core/utils/hive/QueryExecutorJdbc.scala (1)
132-149:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winHandle metadata lookup failures and trigger fallback.
doesTableExistUsingHiveMetadatacan throw (e.g.,SQLException) and currently bubbles up, so theDESCRIBEfallback is skipped when metadata listing fails. That breaks the fail-safe behavior this PR is implementing.Proposed fix
- def doesTableExistUsingHiveMetadata(databaseNameOpt: Option[String], tableName: String): Boolean = { + def doesTableExistUsingHiveMetadata(databaseNameOpt: Option[String], tableName: String): Boolean = { import za.co.absa.pramen.core.utils.UsingUtils.Implicits._ - val conn = getConnection(false) - val metadata = conn.getMetaData - - val db = databaseNameOpt match { - case Some(s) => getEscapedMetadataString(s, metadata) - case None => null - } - - val table = getEscapedMetadataString(tableName, metadata) - - for (rs <- metadata.getTables(null, db, table, HIVE_TABLE_TYPES)) yield { - val exists = rs.next - exists + Try { + val conn = getConnection(false) + val metadata = conn.getMetaData + val db = databaseNameOpt match { + case Some(s) => getEscapedMetadataString(s, metadata) + case None => null + } + val table = getEscapedMetadataString(tableName, metadata) + for (rs <- metadata.getTables(null, db, table, HIVE_TABLE_TYPES)) yield rs.next + }.recover { + case NonFatal(ex) => + log.warn(s"Metadata table existence check failed for '$tableName'. Falling back to DESCRIBE TABLE.", ex) + false } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pramen/core/src/main/scala/za/co/absa/pramen/core/utils/hive/QueryExecutorJdbc.scala` around lines 132 - 149, doesTableExistUsingHiveMetadata currently lets exceptions from metadata.getTables bubble up which prevents the DESCRIBE fallback; wrap the metadata lookup in a try/catch that catches SQLException (or Throwable) and returns false so the caller will run the fallback, and ensure the JDBC Connection from getConnection(false) is always closed (use the existing UsingUtils.Implicits or a try-finally around getConnection(false)). Specifically, in doesTableExistUsingHiveMetadata wrap the call to metadata.getTables(null, db, table, HIVE_TABLE_TYPES) and the ResultSet handling in a safe block that on exception logs/debugs the error and returns false; keep using getEscapedMetadataString for db/table and preserve resource cleanup.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@pramen/core/src/main/scala/za/co/absa/pramen/core/utils/hive/QueryExecutorJdbc.scala`:
- Around line 159-161: The log in QueryExecutorJdbc's DESCRIBE fallback
currently concatenates the exception message without spacing/parentheses; update
the Failure(ex) branch in the method where this appears to build a clearer
message (e.g. use s"The query resulted in an error, assuming the table
$fullTableName does not exist: ${ex.getMessage}" or include the exception as a
parameter to the logger like log.info(message, ex)) so the exception text is
separated and readable; modify the Failure(ex) case accordingly.
In
`@pramen/core/src/test/scala/za/co/absa/pramen/core/tests/utils/hive/QueryExecutorJdbcSuite.scala`:
- Around line 79-85: The test creates my_table2 but checks for MY_TABLE and
ignores the DESCRIBE result; update the calls to target the created table and
assert both outcomes: call qe.doesTableExistUsingHiveMetadata(None, "MY_TABLE2")
(or "my_table2" with matching case expectations) and store the result of
qe.doesTableExistUsingDescribeTable(None, "my_table2") into a variable, then
assert that the Hive-metadata check is true and that the describe-based check
returns the expected value (for HSQL likely false); adjust assertions
accordingly around the qe, doesTableExistUsingHiveMetadata and
doesTableExistUsingDescribeTable calls.
---
Outside diff comments:
In
`@pramen/core/src/main/scala/za/co/absa/pramen/core/utils/hive/QueryExecutorJdbc.scala`:
- Around line 132-149: doesTableExistUsingHiveMetadata currently lets exceptions
from metadata.getTables bubble up which prevents the DESCRIBE fallback; wrap the
metadata lookup in a try/catch that catches SQLException (or Throwable) and
returns false so the caller will run the fallback, and ensure the JDBC
Connection from getConnection(false) is always closed (use the existing
UsingUtils.Implicits or a try-finally around getConnection(false)).
Specifically, in doesTableExistUsingHiveMetadata wrap the call to
metadata.getTables(null, db, table, HIVE_TABLE_TYPES) and the ResultSet handling
in a safe block that on exception logs/debugs the error and returns false; keep
using getEscapedMetadataString for db/table and preserve resource cleanup.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5e6ef570-a649-49c3-a479-cedda9c6698f
📒 Files selected for processing (2)
pramen/core/src/main/scala/za/co/absa/pramen/core/utils/hive/QueryExecutorJdbc.scalapramen/core/src/test/scala/za/co/absa/pramen/core/tests/utils/hive/QueryExecutorJdbcSuite.scala
Unit Test Coverage
Files
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Closes #744
Summary by CodeRabbit
Refactor
Tests