sequel-duckdb 0.2.0 → 0.3.0

data/.kiro/specs/duckdb-sql-syntax-compatibility/design.md

@@ -1,272 +0,0 @@
-# Design Document: DuckDB SQL Syntax Compatibility
-
-## Overview
-
-This design addresses SQL generation issues in the sequel-duckdb adapter where the adapter is generating non-standard SQL syntax that doesn't match Sequel's established conventions. The issues include unwanted ESCAPE clauses in LIKE statements, missing parentheses in complex expressions, incorrect qualified column reference format, and improper subquery column references.
-
-The solution is to fix the adapter's SQL generation methods to produce clean, standard SQL that follows Sequel's patterns while being fully compatible with DuckDB. This ensures consistent SQL generation that matches Sequel's conventions across all operations including LIKE clauses, complex expressions, qualified identifiers, regex operations, and subquery column references.
-
-## Architecture
-
-### Design Philosophy
-
-1. **Fix Root Causes**: Address SQL generation issues in the adapter rather than working around them in tests
-2. **Standard SQL Generation**: Generate clean, standard SQL that follows Sequel's established patterns
-3. **Minimal Adapter Changes**: Make targeted fixes to specific SQL generation methods
-
-### Current Structure (Targeted Fixes)
-
-```
-lib/sequel/adapters/
-├── duckdb.rb                    # Main adapter (unchanged)
-└── shared/
-    └── duckdb.rb               # DatasetMethods (fix SQL generation methods)
-
-test/
-├── sql_test.rb                 # Fix dataset creation issues
-├── dataset_test.rb             # Tests should pass with fixed adapter
-└── spec_helper.rb              # No changes needed
-```
-
-## Components and Interfaces
-
-### 1. LIKE Clause Generation Fix
-
-**Location**: `lib/sequel/adapters/shared/duckdb.rb` - DatasetMethods
-
-Override LIKE handling to prevent unwanted ESCAPE clauses:
-
-```ruby
-def complex_expression_sql_append(sql, op, args)
-  case op
-  when :LIKE
-    # Generate clean LIKE without ESCAPE clause
-    sql << "("
-    literal_append(sql, args[0])
-    sql << " LIKE "
-    literal_append(sql, args[1])
-    sql << ")"
-  when :ILIKE
-    # Convert ILIKE to UPPER() LIKE UPPER() with proper parentheses
-    sql << "(UPPER("
-    literal_append(sql, args[0])
-    sql << ") LIKE UPPER("
-    literal_append(sql, args[1])
-    sql << "))"
-  when :~
-    # Regex with proper parentheses
-    sql << "("
-    literal_append(sql, args[0])
-    sql << " ~ "
-    literal_append(sql, args[1])
-    sql << ")"
-  else
-    super
-  end
-end
-```
-
-### 2. Table Alias Generation Fix
-
-**Location**: `lib/sequel/adapters/shared/duckdb.rb` - DatasetMethods
-
-Override alias handling to use standard AS syntax:
-
-```ruby
-def table_alias_sql_append(sql, table, alias_name)
-  sql << table.to_s
-  sql << " AS "
-  sql << alias_name.to_s
-end
-```
-
-### 3. Qualified Column Reference Fix
-
-**Location**: `lib/sequel/adapters/shared/duckdb.rb` - DatasetMethods
-
-Override qualified identifier handling to use dot notation:
-
-```ruby
-def qualified_identifier_sql_append(sql, table, column)
-  sql << table.to_s
-  sql << "."
-  sql << column.to_s
-end
-```
-
-### 4. Subquery Column Reference Fix
-
-**Location**: `lib/sequel/adapters/shared/duckdb.rb` - DatasetMethods
-
-Ensure subqueries properly reference outer query columns using dot notation:
-
-```ruby
-def subquery_sql_append(sql, ds)
-  # Ensure subqueries use proper column references
-  sql << "("
-  subquery_sql_append_sql(sql, ds.sql)
-  sql << ")"
-end
-
-def exists_sql_append(sql, ds)
-  # EXISTS subqueries with proper column references
-  sql << "EXISTS ("
-  subquery_sql_append_sql(sql, ds.sql)
-  sql << ")"
-end
-```
-
-### 5. SQL Test Infrastructure Fix
-
-**Location**: `test/sql_test.rb`
-
-Fix dataset creation issues in SQL tests:
-
-```ruby
-class SqlTest < SequelDuckDBTest::TestCase
-  def setup
-    super
-    # Use proper mock dataset creation instead of subclasses
-    @dataset = mock_dataset(:users)
-  end
-
-  def test_like_clause_generation
-    dataset = @dataset.where(Sequel.like(:name, "%John%"))
-    expected_sql = "SELECT * FROM users WHERE (name LIKE '%John%')"
-    assert_sql expected_sql, dataset
-  end
-
-  def test_ilike_clause_generation
-    dataset = @dataset.where(Sequel.ilike(:name, "%john%"))
-    expected_sql = "SELECT * FROM users WHERE (UPPER(name) LIKE UPPER('%john%'))"
-    assert_sql expected_sql, dataset
-  end
-
-  def test_subquery_column_references
-    subquery = @dataset.select(:id).where(Sequel.qualify(:users, :active) => true)
-    dataset = @dataset.where(id: subquery)
-    expected_sql = "SELECT * FROM users WHERE (id IN (SELECT id FROM users WHERE (users.active = true)))"
-    assert_sql expected_sql, dataset
-  end
-end
-```
-
-## Data Models
-
-No new data models needed. The existing adapter structure handles SQL generation correctly.
-
-## Error Handling
-
-Use existing Sequel error handling patterns. No special error handling needed for syntax variations since they are all valid SQL.
-
-## Testing Strategy
-
-### 1. SQL Generation Unit Tests
-
-- Test all SQL generation methods using Sequel's mock database functionality
-- Verify exact SQL syntax matches expected Sequel patterns
-- Test LIKE clauses generate clean SQL without ESCAPE clauses
-- Test complex expressions have proper parentheses
-- Test qualified column references use dot notation
-- Test regex expressions are properly formatted and parenthesized
-- Test subquery column references use standard SQL format
-
-### 2. Integration Tests
-
-- Ensure actual database operations work correctly with generated SQL
-- Verify functional correctness alongside syntactic correctness
-- Test correlated subqueries with proper column references
-- Test complex queries with multiple SQL generation features
-
-### 3. Test Infrastructure Consistency
-
-- Fix SQL test infrastructure to use proper dataset creation
-- Ensure tests expect standard SQL syntax consistently
-- Maintain comprehensive test coverage for all SQL generation patterns
-- Use Test-Driven Development approach for all fixes
-
-## Design Decisions and Rationales
-
-### 1. Fix Adapter SQL Generation
-
-**Decision**: Fix the root cause SQL generation issues in the adapter
-**Rationale**: The adapter is generating non-standard SQL that doesn't follow Sequel conventions. Tests are correct to expect standard SQL.
-
-### 2. Targeted Method Overrides
-
-**Decision**: Override specific SQL generation methods in DatasetMethods
-**Rationale**: Surgical fixes to specific issues without disrupting the overall adapter architecture.
-
-### 3. Standard SQL Compliance
-
-**Decision**: Generate SQL that follows standard SQL and Sequel conventions
-**Rationale**: Ensures compatibility with existing Sequel patterns and makes the adapter more predictable.
-
-### 4. Maintain Test Coverage
-
-**Decision**: Keep all existing tests, fix the adapter to make them pass
-**Rationale**: Tests are validating correct behavior; the adapter should conform to expected patterns.
-
-## Implementation Phases
-
-### Phase 1: Fix LIKE and Complex Expression Generation
-
-- Override `complex_expression_sql_append` to fix LIKE, ILIKE, and regex generation
-- Add proper parentheses to all complex expressions
-- Remove unwanted ESCAPE clauses from LIKE statements
-
-### Phase 2: Fix Table Alias Generation
-
-- Override table alias methods to use standard `AS` syntax
-- Ensure aliases work correctly in JOIN operations
-
-### Phase 3: Fix Qualified Column References
-
-- Override qualified identifier methods to use dot notation
-- Ensure subqueries use proper column references
-
-### Phase 4: Fix SQL Test Infrastructure
-
-- Fix dataset creation issues in SQL tests
-- Ensure tests use proper mock datasets
-
-### Phase 5: Verification and Documentation
-
-- Run all tests to ensure they pass with fixed adapter
-- Document the SQL generation patterns used by the adapter
-- Create comprehensive documentation of DuckDB-specific SQL patterns
-- Update API documentation with SQL generation examples
-
-## Documentation Strategy
-
-### SQL Pattern Documentation
-
-To address Requirement 7, the adapter will include comprehensive documentation of SQL generation patterns:
-
-**Location**: `API_DOCUMENTATION.md` and inline code comments
-
-1. **LIKE Clause Patterns**: Document how LIKE clauses are generated without ESCAPE clauses
-2. **Complex Expression Formatting**: Document parentheses usage in ILIKE and regex expressions
-3. **Qualified Column References**: Document dot notation usage for table.column references
-4. **Subquery Column References**: Document proper column referencing in correlated subqueries
-5. **DuckDB-Specific Optimizations**: Document any DuckDB-specific SQL optimizations used
-
-**Example Documentation Structure**:
-
-```ruby
-# SQL Generation Patterns for DuckDB Adapter
-#
-# LIKE Clauses:
-#   Input:  Sequel.like(:name, "%John%")
-#   Output: (name LIKE '%John%')
-#
-# ILIKE Clauses:
-#   Input:  Sequel.ilike(:name, "%john%")
-#   Output: (UPPER(name) LIKE UPPER('%john%'))
-#
-# Qualified Columns:
-#   Input:  Sequel.qualify(:users, :id)
-#   Output: users.id
-```
-
-This design fixes the root causes of the SQL generation issues rather than working around them, resulting in a more robust and standards-compliant adapter.

data/.kiro/specs/duckdb-sql-syntax-compatibility/requirements.md

@@ -1,84 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-This specification addresses SQL generation issues in the sequel-duckdb adapter where the adapter is generating non-standard SQL syntax that doesn't match expected Sequel conventions. The adapter should generate clean, standard SQL that follows Sequel's established patterns while being compatible with DuckDB. The issues are in the adapter's SQL generation logic, not in DuckDB's SQL support.
-
-## Requirements
-
-### Requirement 1: LIKE Clause Clean Generation
-
-**User Story:** As a developer using Sequel with DuckDB, I want LIKE clauses to generate clean SQL without unnecessary ESCAPE clauses, so that the SQL matches standard Sequel patterns.
-
-#### Acceptance Criteria
-
-1. WHEN I use `Sequel.like(:name, "%John%")` THEN the generated SQL SHALL be `(name LIKE '%John%')` without ESCAPE clause
-2. WHEN I use LIKE patterns with special characters THEN they SHALL work without requiring explicit ESCAPE clauses
-3. WHEN I use ILIKE patterns THEN they SHALL be converted to `(UPPER(column) LIKE UPPER(pattern))` with proper parentheses
-4. WHEN tests check LIKE clause generation THEN they SHALL expect clean SQL without ESCAPE additions
-
-### Requirement 2: Complex Expression Parentheses
-
-**User Story:** As a developer using Sequel with DuckDB, I want complex expressions to be properly parenthesized in generated SQL, so that the SQL follows standard Sequel formatting conventions.
-
-#### Acceptance Criteria
-
-1. WHEN I use ILIKE expressions THEN they SHALL be wrapped in parentheses: `(UPPER(column) LIKE UPPER(pattern))`
-2. WHEN I use regex expressions THEN they SHALL be wrapped in parentheses: `(column ~ 'pattern')`
-3. WHEN I use boolean comparisons with `=~` THEN they SHALL generate proper `IS` syntax with parentheses
-4. WHEN tests check complex expressions THEN they SHALL expect properly parenthesized SQL
-
-### Requirement 3: Standard Qualified Column References
-
-**User Story:** As a developer using Sequel with DuckDB, I want qualified column references to use standard SQL dot notation, so that the generated SQL follows established SQL conventions.
-
-#### Acceptance Criteria
-
-1. WHEN I reference columns across tables THEN they SHALL use `table.column` syntax
-2. WHEN I use qualified column names in subqueries THEN they SHALL use proper dot notation
-3. WHEN I use schema-qualified names THEN they SHALL use standard SQL format
-4. WHEN tests check qualified identifiers THEN they SHALL expect standard dot notation
-
-### Requirement 4: Proper Regular Expression Formatting
-
-**User Story:** As a developer using Sequel with DuckDB, I want regular expression matching to generate properly formatted SQL with parentheses, so that the SQL follows Sequel's formatting conventions.
-
-#### Acceptance Criteria
-
-1. WHEN I use regex matching with `~` operator THEN it SHALL generate `(column ~ 'pattern')` with parentheses
-2. WHEN I use case-insensitive regex THEN it SHALL be properly formatted with parentheses
-3. WHEN I use complex regex patterns THEN they SHALL be properly formatted and parenthesized
-4. WHEN tests check regex syntax THEN they SHALL expect properly parenthesized expressions
-
-### Requirement 5: Standard Subquery Column References
-
-**User Story:** As a developer using Sequel with DuckDB, I want subqueries to properly reference outer query columns using standard SQL dot notation, so that correlated subqueries follow SQL conventions.
-
-#### Acceptance Criteria
-
-1. WHEN I use correlated subqueries THEN column references SHALL use `table.column` syntax
-2. WHEN I reference outer query columns THEN they SHALL be properly qualified with dot notation
-3. WHEN I use EXISTS subqueries THEN column references SHALL use standard SQL format
-4. WHEN tests check subquery references THEN they SHALL expect standard dot notation
-
-### Requirement 6: Consistent SQL Generation Testing
-
-**User Story:** As a developer maintaining the sequel-duckdb adapter, I want tests to verify that the adapter generates consistent, standard SQL, so that the adapter follows Sequel's established patterns.
-
-#### Acceptance Criteria
-
-1. WHEN tests check SQL generation THEN they SHALL expect standard SQL syntax
-2. WHEN the adapter generates SQL THEN it SHALL be consistent with Sequel's conventions
-3. WHEN SQL generation issues are found THEN they SHALL be fixed in the adapter, not worked around in tests
-4. WHEN SQL correctness is verified THEN both functional and syntactic correctness SHALL be maintained
-
-### Requirement 7: Documentation of SQL Generation Patterns
-
-**User Story:** As a developer using the sequel-duckdb adapter, I want to understand how the adapter generates SQL for DuckDB, so that I can write queries that work optimally with the adapter.
-
-#### Acceptance Criteria
-
-1. WHEN the adapter generates specific SQL patterns THEN they SHALL be documented
-2. WHEN SQL generation differs from other Sequel adapters THEN the differences SHALL be explained
-3. WHEN DuckDB-specific optimizations are used THEN they SHALL be documented with examples
-4. WHEN SQL generation patterns change THEN documentation SHALL be updated accordingly

data/.kiro/specs/duckdb-sql-syntax-compatibility/tasks.md

@@ -1,107 +0,0 @@
-# Implementation Plan
-
-- [x] 1. Identify failing tests and analyze DuckDB SQL generation
-
-  - Run existing test suite to identify tests failing due to SQL syntax differences
-  - Analyze what SQL the adapter currently generates vs what tests expect
-  - Document the specific DuckDB syntax patterns that are being generated
-  - Determine if adapter changes are needed or just test expectation updates
-  - _Requirements: 7.1, 7.2_
-
-- [x] 2. Fix LIKE clause ESCAPE handling in adapter
-
-  - Current issue: LIKE generates `(name LIKE '%John%' ESCAPE '\')` instead of `(name LIKE '%John%')`
-  - Override LIKE handling in `complex_expression_sql_append` to remove ESCAPE clause
-  - Ensure LIKE clauses generate clean `(name LIKE '%John%')` without ESCAPE clause
-  - Write tests to verify LIKE functionality works correctly without the ESCAPE clause
-  - _Requirements: 1.1, 1.2, 1.4_
-
-- [x] 3. Fix parentheses in complex expression SQL generation
-
-  - Current issue: ILIKE generates `UPPER(name) LIKE UPPER('%john%')` without outer parentheses
-  - Current issue: Regex generates `name ~ 'pattern'` without outer parentheses
-  - Update `complex_expression_sql_append` to add proper parentheses around expressions
-  - Ensure ILIKE generates `(UPPER(name) LIKE UPPER('%john%'))` with parentheses
-  - Ensure regex generates `(name ~ '^John')` with parentheses around the expression
-  - Write tests to verify all complex expressions have consistent parentheses
-  - _Requirements: 1.3, 5.1, 5.2, 5.3, 5.4_
-
-- [x] 4. ~~Fix table alias syntax to use AS instead of triple underscore~~ (REMOVED - Not a core Sequel feature)
-
-  - The `table___alias` syntax is not a core Sequel feature and requires an extension
-  - Removed implementation and tests as this is not standard Sequel functionality
-  - Standard Sequel table aliases use `.as()` method: `db[:users].as(:u)`
-
-- [x] 5. Fix qualified column references to use dot notation
-
-  - Current issue: Qualified columns generate `users__id` instead of `users.id`
-  - Override qualified identifier handling to generate proper dot notation
-  - Implement `qualified_identifier_sql_append` method to use dot notation
-  - Ensure subqueries use correct `users.id` column reference format
-  - Write tests to verify qualified column references work correctly in complex queries
-  - _Requirements: 4.1, 4.2, 4.3, 4.4, 6.1, 6.2, 6.3, 6.4_
-
-- [x] 6. Fix SQL test infrastructure issues
-
-  - Current issue: SQL tests failing with dataset type assertion errors (`Expected #<Sequel::Dataset::_Subclass>`)
-  - Fix `SqlTest` class to use proper dataset creation instead of mock subclasses
-  - Update SQL generation tests to work with actual DuckDB adapter behavior
-  - Ensure tests create proper datasets for SQL generation testing
-  - Fix dataset type assertion issues in SQL tests
-  - _Requirements: 6.1, 6.2_
-
-- [x] 7. Fix recursive CTE SQL generation
-
-  - Current issue: `WITH RECURSIVE` generates incorrect SQL without RECURSIVE keyword
-  - Implement proper recursive CTE handling in dataset methods
-  - Ensure recursive CTEs generate `WITH RECURSIVE` syntax correctly
-  - Test recursive CTE functionality with proper SQL generation
-  - _Requirements: 5.1, 5.2, 5.3, 5.4_
-
-- [x] 8. Fix JOIN USING clause generation
-
-  - Current issue: `JOIN USING` clause not generating USING syntax correctly
-  - Implement proper USING clause handling in JOIN operations
-  - Ensure JOIN USING generates correct `INNER JOIN table USING (column)` syntax
-  - Test JOIN USING functionality with various column combinations
-  - _Requirements: 4.1, 4.2, 4.3, 4.4_
-
-- [x] 9. Fix regex functionality integration
-
-  - Current issue: Regex matching returning 0 results instead of expected matches
-  - Debug regex operator implementation in complex_expression_sql_append
-  - Ensure regex patterns work correctly with DuckDB's regex syntax
-  - Test regex functionality with actual data and pattern matching
-  - _Requirements: 1.3, 5.1, 5.2, 5.3, 5.4_
-
-- [x] 10. Fix model integration issues
-
-  - Current issue: Model tests failing with type mapping and update detection
-  - Fix time type mapping (currently returning :datetime instead of :time)
-  - Fix model update detection to properly track changed fields
-  - Ensure model DELETE operations work correctly with proper ID handling
-  - _Requirements: 2.1, 2.2, 2.3, 2.4_
-
-- [x] 11. Fix table creation and schema issues
-
-  - Current issue: Tests failing because tables don't exist during SQL execution
-  - Ensure proper table creation in test setup for integration tests
-  - Fix primary key handling for tables without explicit primary keys
-  - Handle NOT NULL constraint violations properly in INSERT operations
-  - _Requirements: 3.1, 3.2, 3.3, 3.4_
-
-- [x] 12. Verify all tests pass with consistent DuckDB SQL generation
-
-  - Run complete test suite to ensure all SQL generation tests pass
-  - Verify that adapter generates consistent, predictable SQL for DuckDB
-  - Test integration scenarios to ensure functional correctness
-  - Fix any remaining test expectation mismatches
-  - _Requirements: 6.1, 6.2, 6.3, 6.4_
-
-- [x] 13. Document DuckDB-specific SQL syntax patterns
-
-  - Document the specific SQL syntax that the adapter generates for DuckDB
-  - Provide examples of DuckDB SQL patterns used by the adapter
-  - Explain why certain DuckDB syntax choices were made
-  - Create reference documentation for developers using the adapter
-  - _Requirements: 7.1, 7.2, 7.3_

data/.kiro/specs/edge-cases-and-validation-fixes/requirements.md

@@ -1,32 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-After comprehensive review of the current sequel-duckdb adapter implementation and testing against the actual behavior, all previously identified edge cases and validation issues have been determined to be either:
-
-1. **Already implemented** - The adapter includes comprehensive error handling, data type conversion, SQL injection prevention through parameterized queries, connection management, and transaction support.
-
-2. **Handled by Sequel core** - Query parameter validation (LIMIT/OFFSET edge cases) is handled by the Sequel framework itself before reaching database adapters.
-
-3. **Working as designed** - DuckDB's native behavior for edge cases is appropriate and doesn't require additional adapter-level handling.
-
-4. **Out of scope** - Some edge cases (like system resource management) are better handled at the application or infrastructure level rather than in a database adapter.
-
-## Current Status
-
-The sequel-duckdb adapter currently provides:
-
-- ✅ Comprehensive error handling and mapping to appropriate Sequel exception types
-- ✅ Robust connection management with proper error handling
-- ✅ Complete data type conversion and validation
-- ✅ SQL injection prevention through parameterized queries
-- ✅ Transaction support with proper rollback handling
-- ✅ Schema introspection and DDL operations
-- ✅ Performance optimizations for large datasets
-- ✅ Memory management for streaming operations
-
-## Conclusion
-
-No additional edge case or validation requirements have been identified that would add meaningful value to the adapter. The current implementation provides robust handling of edge cases appropriate for a production database adapter.
-
-This specification is considered complete with no outstanding requirements.

data/.kiro/specs/integration-test-database-setup/requirements.md

@@ -1,117 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-This specification addresses database schema and setup issues in integration tests for the sequel-duckdb adapter. Many integration tests are failing because they attempt to perform database operations on tables that don't exist or haven't been properly set up. The test infrastructure needs proper database setup, schema management, and teardown procedures to ensure integration tests run reliably.
-
-## Requirements
-
-### Requirement 1: Automatic Test Database Setup
-
-**User Story:** As a developer running integration tests for the sequel-duckdb adapter, I want test databases to be automatically set up with required schemas, so that tests can focus on functionality rather than database preparation.
-
-#### Acceptance Criteria
-
-1. WHEN integration tests start THEN required test tables SHALL be automatically created
-2. WHEN tests need specific schemas THEN they SHALL be set up before test execution
-3. WHEN tests require sample data THEN it SHALL be inserted during setup
-4. WHEN test setup fails THEN clear error messages SHALL indicate the specific failure
-
-### Requirement 2: Test Table Schema Management
-
-**User Story:** As a developer writing integration tests for the sequel-duckdb adapter, I want standardized test table schemas that cover all data types and scenarios, so that I can test comprehensive functionality without custom setup.
-
-#### Acceptance Criteria
-
-1. WHEN tests need a users table THEN it SHALL include common columns (id, name, email, age, active, created_at)
-2. WHEN tests need type testing THEN tables SHALL include all supported DuckDB data types
-3. WHEN tests need relationship testing THEN foreign key relationships SHALL be properly set up
-4. WHEN tests need constraint testing THEN appropriate constraints SHALL be defined
-
-### Requirement 3: Test Data Fixtures
-
-**User Story:** As a developer running integration tests for the sequel-duckdb adapter, I want consistent test data fixtures, so that tests produce predictable results and can be easily debugged.
-
-#### Acceptance Criteria
-
-1. WHEN tests need sample users THEN standardized user records SHALL be available
-2. WHEN tests need relational data THEN properly linked records SHALL be provided
-3. WHEN tests need edge case data THEN fixtures SHALL include boundary values and special cases
-4. WHEN tests need large datasets THEN performance test fixtures SHALL be available
-
-### Requirement 4: Database Cleanup and Isolation
-
-**User Story:** As a developer running integration tests for the sequel-duckdb adapter, I want each test to run in isolation with a clean database state, so that tests don't interfere with each other and produce consistent results.
-
-#### Acceptance Criteria
-
-1. WHEN each test starts THEN it SHALL have a clean database state
-2. WHEN tests modify data THEN changes SHALL not affect subsequent tests
-3. WHEN tests create temporary tables THEN they SHALL be cleaned up after the test
-4. WHEN tests fail THEN database state SHALL be reset for the next test
-
-### Requirement 5: Schema Introspection Test Support
-
-**User Story:** As a developer testing schema introspection features of the sequel-duckdb adapter, I want test databases with comprehensive schema elements, so that I can verify all introspection functionality works correctly.
-
-#### Acceptance Criteria
-
-1. WHEN testing table listing THEN multiple test tables SHALL exist
-2. WHEN testing column introspection THEN tables SHALL have diverse column types and properties
-3. WHEN testing index introspection THEN various index types SHALL be present
-4. WHEN testing constraint introspection THEN different constraint types SHALL be available
-
-### Requirement 6: Transaction Testing Support
-
-**User Story:** As a developer testing transaction functionality of the sequel-duckdb adapter, I want test scenarios that properly exercise transaction behavior, so that I can verify commit, rollback, and isolation work correctly.
-
-#### Acceptance Criteria
-
-1. WHEN testing transactions THEN test data SHALL support rollback verification
-2. WHEN testing nested transactions THEN appropriate test scenarios SHALL be available
-3. WHEN testing transaction isolation THEN concurrent test scenarios SHALL be supported
-4. WHEN testing transaction errors THEN error conditions SHALL be reproducible
-
-### Requirement 7: Performance Testing Database Setup
-
-**User Story:** As a developer testing performance aspects of the sequel-duckdb adapter, I want test databases with appropriate data volumes, so that I can verify performance optimizations work correctly.
-
-#### Acceptance Criteria
-
-1. WHEN testing bulk operations THEN large datasets SHALL be available
-2. WHEN testing query performance THEN indexed and non-indexed scenarios SHALL be set up
-3. WHEN testing memory usage THEN datasets of various sizes SHALL be available
-4. WHEN testing streaming THEN large result sets SHALL be available for testing
-
-### Requirement 8: Error Condition Testing Setup
-
-**User Story:** As a developer testing error handling in the sequel-duckdb adapter, I want test scenarios that reliably reproduce error conditions, so that I can verify proper error handling and exception mapping.
-
-#### Acceptance Criteria
-
-1. WHEN testing constraint violations THEN tables with constraints SHALL be available
-2. WHEN testing connection errors THEN invalid database scenarios SHALL be reproducible
-3. WHEN testing SQL errors THEN scenarios that trigger DuckDB errors SHALL be available
-4. WHEN testing type errors THEN incompatible data scenarios SHALL be set up
-
-### Requirement 9: Test Database Configuration
-
-**User Story:** As a developer running integration tests for the sequel-duckdb adapter, I want flexible test database configuration, so that tests can run in different environments and scenarios.
-
-#### Acceptance Criteria
-
-1. WHEN tests run in CI THEN database configuration SHALL be automatically appropriate
-2. WHEN tests run locally THEN database configuration SHALL support development workflows
-3. WHEN tests need specific DuckDB settings THEN configuration SHALL be easily adjustable
-4. WHEN tests need different database sizes THEN memory limits SHALL be configurable
-
-### Requirement 10: Test Helper Integration
-
-**User Story:** As a developer writing integration tests for the sequel-duckdb adapter, I want test helpers that work seamlessly with the database setup, so that I can write tests efficiently without boilerplate code.
-
-#### Acceptance Criteria
-
-1. WHEN using test helpers THEN they SHALL work with the established database schema
-2. WHEN creating test data THEN helpers SHALL use the standardized fixtures
-3. WHEN verifying results THEN helpers SHALL understand the test database structure
-4. WHEN cleaning up THEN helpers SHALL properly reset database state