PLUGIN-1950 : Log zero records for Table mode and SQL Statement mode.

[sahusanket]

Add Logging for Empty Tables and Queries in Multi-Table Plugins

Problem

When reading from multiple database tables or executing multiple SQL statements, there is currently no visibility into which tables or queries yielded zero records.

Solution

This PR adds informational logging whenever an ingestion source (table or custom query) produces exactly zero records.

Key Changes

1. Empty Table Detection in Multi-Table Mode:

   • MultiTableDBInputFormat: Updated getTableSplits to explicitly detect when a table is empty (bounding query returns NULL, NULL) and return exactly one full-table split (1=1).
   • DBTableRecordReader: Added logging to emit Source table '<fullTableName>' has zero records. when exactly zero rows are read. Verified that the reader is processing a full-table split (1=1) to prevent false alarms on empty partial splits when splitsPerTable > 1.

2. Improved Logging in SQL Statement Mode:

   • SQLStatementRecordReader: Added logging to emit SQL statement '<id>' ('<query>') has zero records. when exactly zero rows are read.

Testing

1. Verified in CDAP Sandbox that it is able to log the statement for Empty Table with splits = 4

2. Verified in CDAP Sandbox that it is able to log the statement for SQL statement mode

3. Also verified that in case of Proper data, it is not printing this LOG LINE.

4. Verified in PROD environment as well.

[gemini-code-assist]

Code Review

This pull request introduces logging to identify when source tables or SQL statements return zero records, enhancing observability. It also updates MultiTableDBInputFormat to handle cases where split boundaries are null by returning a single default split. Feedback was provided regarding SQLStatementRecordReader to move the full SQL statement logging from INFO to DEBUG level to prevent the exposure of sensitive information and avoid log bloat.

[gemini-code-assist]

Logging the full SQL statement at INFO level can expose sensitive information (such as PII or credentials in the WHERE clause) in the logs. It can also lead to log bloat for very large queries. Consider logging only the statement ID at INFO level and moving the full query to DEBUG level.

          LOG.info("SQL statement '{}' has zero records.", split.getId());
          LOG.debug("SQL statement '{}' ('{}') has zero records.", split.getId(), split.getSqlStatement());