refactor: rewrite sample/issue922.rb to use table adapter pattern

[suketa]

Summary

Rewrites sample/issue922.rb to use the table adapter pattern, consistent with the approach in sample/issue930.rb.

Changes

• Remove monkey-patches on DuckDB::TableFunction, DuckDB::Connection, and DuckDB::Polars::DataFrame
• Add PolarsDataFrameTableAdapter class following the same structure as CSVTableAdapter
• Register via DuckDB::TableFunction.add_table_adapter(Polars::DataFrame, ...)
• Use con.expose_as_table instead of con.create_table_function
• All RuboCop offenses resolved

Summary by CodeRabbit

• Refactor
  • Refactored Polars DataFrame integration with DuckDB to optimize data streaming performance and row handling efficiency
  • Introduced dedicated adapter architecture to improve management of table function operations, registration, and data exposure
  • Enhanced code clarity and maintainability through improved structural organization

[coderabbitai]

📝 Walkthrough

Walkthrough

This change introduces a PolarsDataFrameTableAdapter class to handle Polars DataFrame integration with DuckDB, replacing inline table-function wiring. The public API shifts from create_table_function to expose_as_table, with adapter registration now handled via DuckDB::TableFunction.add_table_adapter.

Changes

Cohort / File(s)	Summary
Polars DataFrame Table Adapter Refactoring sample/issue922.rb	Introduced PolarsDataFrameTableAdapter class with public call(data_frame, name, columns: nil) method and private helpers (execute_block, write_row, infer_columns). Replaced con.create_table_function(df, 'polars_df') with con.expose_as_table(df, 'polars_df') and moved DataFrame construction to occur after adapter registration via DuckDB::TableFunction.add_table_adapter.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

• refactor: rewrite sample/issue930*.rb to use table adapter pattern #1118: Implements the same table-adapter pattern with the call/write_row/infer_columns methods and uses DuckDB::TableFunction.add_table_adapter for registration alongside expose_as_table API.
• Issue922 sample script #1114: Related Polars DataFrame to DuckDB table-function integration implementation with similar adapter and registration patterns.
• add table adapter functionality #1115: Introduces the expose_as_table and TableFunction.add_table_adapter APIs that this PR adopts.

Poem

🐰 A DataFrame hopped into DuckDB's embrace,
Through adapters and tables, they found their place,
Polars dance with DuckDB in harmony—
Streams of data flowing wild and free!
✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: refactoring sample/issue922.rb to implement the table adapter pattern, which aligns with the PR objectives and the summary of changes.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch sample/issue922-use-table-adapter

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

sample/issue922.rb (2)

45-54: Use block form for automatic resource cleanup instead of manual begin/ensure.

If any statement raises an exception between lines 47–51, cleanup is skipped. Use the block form for automatic cleanup:

DuckDB::Database.open do |db|
  db.connect do |con|
    con.query('SET threads=1')
    con.expose_as_table(df, 'polars_df')
    result = con.query('SELECT * FROM polars_df()').to_a
    p result
    puts result.first.first == '1'
  end
end

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@sample/issue922.rb` around lines 45 - 54, Replace the manual
open/connect/close pattern with the block form to ensure automatic cleanup: wrap
the Database.open call with a block and inside it call db.connect with a block,
then move the calls to con.query('SET threads=1'), con.expose_as_table(df,
'polars_df'), the SELECT query and printing logic into that inner block so
resources are closed automatically instead of calling con.close and db.close;
refer to DuckDB::Database.open, db.connect, con.query and con.expose_as_table to
locate the relevant code to change.

---

31-32: Implement dtype-to-LogicalType mapping for Polars columns in infer_columns.

The current implementation coerces all columns to VARCHAR, which loses native Polars type information and forces numeric values to strings (e.g., 1 becomes '1'). Consider mapping Polars dtypes to DuckDB logical types—for example, Int64 → DuckDB::LogicalType::BIGINT, Float64 → DuckDB::LogicalType::DOUBLE, Boolean → DuckDB::LogicalType::BOOLEAN, and Date → DuckDB::LogicalType::DATE, with VARCHAR as fallback for unmapped types.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@sample/issue922.rb` around lines 31 - 32, The infer_columns method currently
maps every Polars column to DuckDB::LogicalType::VARCHAR; update infer_columns
to inspect each column's Polars dtype and map it to the appropriate
DuckDB::LogicalType (e.g., Int64 -> DuckDB::LogicalType::BIGINT, Float64 ->
DuckDB::LogicalType::DOUBLE, Boolean -> DuckDB::LogicalType::BOOLEAN, Date ->
DuckDB::LogicalType::DATE) and fall back to DuckDB::LogicalType::VARCHAR for
unknown dtypes; modify the code that builds data_frame.columns.to_h so it
queries each column's dtype (via Polars column dtype accessor) and returns the
mapped DuckDB::LogicalType for that header.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@sample/issue922.rb`:
- Around line 45-54: Replace the manual open/connect/close pattern with the
block form to ensure automatic cleanup: wrap the Database.open call with a block
and inside it call db.connect with a block, then move the calls to
con.query('SET threads=1'), con.expose_as_table(df, 'polars_df'), the SELECT
query and printing logic into that inner block so resources are closed
automatically instead of calling con.close and db.close; refer to
DuckDB::Database.open, db.connect, con.query and con.expose_as_table to locate
the relevant code to change.
- Around line 31-32: The infer_columns method currently maps every Polars column
to DuckDB::LogicalType::VARCHAR; update infer_columns to inspect each column's
Polars dtype and map it to the appropriate DuckDB::LogicalType (e.g., Int64 ->
DuckDB::LogicalType::BIGINT, Float64 -> DuckDB::LogicalType::DOUBLE, Boolean ->
DuckDB::LogicalType::BOOLEAN, Date -> DuckDB::LogicalType::DATE) and fall back
to DuckDB::LogicalType::VARCHAR for unknown dtypes; modify the code that builds
data_frame.columns.to_h so it queries each column's dtype (via Polars column
dtype accessor) and returns the mapped DuckDB::LogicalType for that header.

---

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 63cfc32 and 8fc446d.

📒 Files selected for processing (1)

• sample/issue922.rb