feat: Add UPDATE statement support #59
Conversation
- Add Update variant to Statement enum with table, assignments, and where_clause - Parse UPDATE table SET col = val, ... WHERE ... statements - Support multiple column assignments in SET clause - Implement two-phase atomic update execution in executor - Reuse ExpressionEvaluator for WHERE clause filtering - Add type checking for column/value type mismatches - Add Updated variant to ExecutionResult - Add comprehensive unit tests for parser and executor Closes aviralgarg05#46
Learn moreAll Green is an AI agent that automatically: ✅ Addresses code review comments ✅ Fixes failing CI checks ✅ Resolves merge conflicts |
WalkthroughAdds SQL UPDATE support end-to-end: parser recognizes UPDATE with assignments and optional WHERE, planner produces an Update plan, executor performs two-phase update with per-row WHERE evaluation, type checks and atomic batch writes (via new StorageEngine::batch_set). Also adds a cache fixture Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Parser
participant Planner
participant Executor
participant Storage
Client->>Parser: "UPDATE table SET col=val, ... WHERE cond"
Parser->>Parser: Parse → Statement::Update (assignments, maybe WHERE)
Parser-->>Planner: Statement::Update
Planner->>Planner: Build Plan::Update (table, columns)
Planner-->>Executor: Plan::Update
Executor->>Storage: Read table rows
Storage-->>Executor: Rows
rect rgb(245 245 255)
Executor->>Executor: Phase 1 — Evaluate WHERE per row\nValidate assignment types\nCollect candidate row updates
end
rect rgb(240 255 240)
Executor->>Executor: Phase 2 — Serialize updated rows\nPrepare batch operations
end
Executor->>Storage: Write batch updates (batch_set)
Storage-->>Executor: Persisted
Executor-->>Client: ExecutionResult::Updated { table, rows }
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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)
nexum_core/src/executor/mod.rs (1)
279-283: StorageEngine::clone creates a new empty database, not a true clone.This
Cloneimplementation returns a fresh in-memory storage instance, discarding all existing data. If any code relies on cloning to preserve data, it will silently lose all stored rows.This is particularly dangerous because
Cloneis typically expected to produce a semantically equivalent copy.🔎 Suggested alternatives
Remove the
Cloneimpl and refactor code that needs shared access to useArc<StorageEngine>instead.Rename to a more explicit method if creating a new empty instance is intentional:
impl StorageEngine { pub fn new_empty_memory() -> Result<Self> { StorageEngine::memory() } }
- If true cloning is needed, implement data copying (though this may be expensive for large datasets).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (5)
cache/test_cache.jsonnexum_core/src/executor/mod.rsnexum_core/src/sql/parser.rsnexum_core/src/sql/planner.rsnexum_core/src/sql/types.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
⚙️ CodeRabbit configuration file
Focus on Rust best practices, memory safety, error handling, and idiomatic code patterns.
Files:
nexum_core/src/sql/types.rsnexum_core/src/executor/mod.rsnexum_core/src/sql/parser.rsnexum_core/src/sql/planner.rs
🧬 Code graph analysis (2)
nexum_core/src/executor/mod.rs (5)
nexum_core/src/executor/filter.rs (1)
new(53-55)nexum_core/src/catalog/mod.rs (1)
new(18-20)nexum_core/src/storage/engine.rs (2)
new(10-13)memory(15-21)nexum_core/src/sql/parser.rs (1)
assignments(72-79)nexum_core/src/sql/types.rs (1)
data_type(23-31)
nexum_core/src/sql/planner.rs (1)
nexum_core/src/sql/parser.rs (1)
assignments(72-79)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Rust benchmarks
- GitHub Check: Python tests
🔇 Additional comments (14)
cache/test_cache.json (1)
1-787: Test fixture data looks appropriate.This JSON file provides test cache entries for semantic query caching. The structure is valid and the metadata fields (
similarity_threshold,cache_size,format_version) are well-defined.Note that while this PR adds UPDATE statement support, these cache entries contain only SELECT queries. Consider adding UPDATE query cache entries if the semantic cache is intended to support UPDATE statements as well.
nexum_core/src/sql/types.rs (1)
70-74: Well-structured Update variant.The
Updatevariant follows the established patterns in this enum. UsingOption<Box<Expr>>forwhere_clauseis consistent with theSelectvariant, andVec<(String, Value)>for assignments is appropriate for representing column-value pairs.nexum_core/src/sql/planner.rs (2)
17-21: Plan::Update variant is well-designed.The variant captures essential planning metadata: target table, affected columns, and whether a WHERE clause is present.
44-52: Planning logic for UPDATE is correct.The implementation correctly extracts column names from assignments and determines WHERE clause presence for plan metadata.
nexum_core/src/sql/parser.rs (3)
64-88: UPDATE parsing implementation looks correct.The parsing logic properly extracts table name, assignments, and optional WHERE clause. The column name construction using
join(".")correctly handles compound identifiers.
266-285: Multi-column UPDATE test is comprehensive.The test validates multiple assignments are parsed correctly with their column names.
287-304: UPDATE without WHERE test covers important edge case.This ensures the parser correctly handles UPDATE statements that affect all rows.
nexum_core/src/executor/mod.rs (7)
165-198: UPDATE validation and type checking logic is sound.The implementation correctly:
- Validates table existence
- Builds column index mapping
- Performs type checking with appropriate Null handling
- Returns clear error messages for type mismatches
One minor consideration: the type checking allows
Nullfor any column regardless of whether the schema permits nulls. If nullable constraints are added later, this logic will need updating.
200-232: Two-phase collection with WHERE evaluation is well-implemented.The approach of collecting all qualifying rows before applying updates prevents issues with iterating over a changing dataset. The early return on WHERE evaluation failure ensures no partial updates occur during the collection phase.
298-301: ExecutionResult::Updated variant is appropriate.The variant provides the necessary feedback (table name and row count) for UPDATE operations.
366-459: Comprehensive test for UPDATE with WHERE clause.The test properly:
- Sets up table and data
- Constructs WHERE clause using sqlparser
- Executes UPDATE and verifies row count
- Validates the specific row was updated via SELECT
Good use of verification query to confirm the update took effect.
461-538: Multi-column UPDATE test validates assignment handling.The test ensures multiple assignments are applied correctly to the same row.
540-606: UPDATE all rows test covers the no-WHERE-clause scenario.Good coverage for the case where all rows should be updated, with proper verification that every row received the new value.
304-364: Existing end-to-end test remains valid.The original test continues to verify basic CRUD operations work correctly.
| #[test] | ||
| fn test_parse_update_single_column() { | ||
| let sql = "UPDATE users SET name = 'Bob' WHERE id = 1"; | ||
| let stmt = Parser::parse(sql).unwrap(); | ||
|
|
||
| match stmt { | ||
| Statement::Update { | ||
| table, | ||
| assignments, | ||
| where_clause, | ||
| } => { | ||
| assert_eq!(table, "users"); | ||
| assert_eq!(assignments.len(), 1); | ||
| assert_eq!(assignments[0].0, "name"); | ||
| assert!(where_clause.is_some()); | ||
| } | ||
| _ => panic!("Expected Update statement"), | ||
| } | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Good test coverage for single-column UPDATE.
Consider also asserting the parsed value to ensure complete correctness:
assert_eq!(assignments[0].1, Value::Text("Bob".to_string()));🤖 Prompt for AI Agents
In nexum_core/src/sql/parser.rs around lines 246 to 264, the test checks the
assignment key but not the assigned value; update the test to assert the parsed
value equals the expected Value::Text("Bob".to_string()) (e.g.,
assert_eq!(assignments[0].1, Value::Text("Bob".to_string()))), and if necessary
bring the Value enum into scope or fully-qualify it so the test compiles.
- Run cargo fmt to fix formatting issues - Add batch_set method to StorageEngine for true atomic updates - Use sled's batch operations to ensure UPDATE atomicity - Add test for batch_set functionality Addresses CodeRabbit feedback on atomicity concerns.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
nexum_core/src/sql/parser.rs (1)
251-269: Tests verify structure but not parsed values.The tests assert assignment keys but not the assigned values. Consider adding value assertions for completeness.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
nexum_core/src/executor/mod.rsnexum_core/src/sql/parser.rsnexum_core/src/storage/engine.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
⚙️ CodeRabbit configuration file
Focus on Rust best practices, memory safety, error handling, and idiomatic code patterns.
Files:
nexum_core/src/storage/engine.rsnexum_core/src/executor/mod.rsnexum_core/src/sql/parser.rs
🧬 Code graph analysis (2)
nexum_core/src/storage/engine.rs (2)
nexum_ai/optimizer.py (1)
get(62-72)nexum_core/src/bridge/mod.rs (1)
get(84-97)
nexum_core/src/executor/mod.rs (5)
nexum_core/src/storage/engine.rs (2)
new(10-13)memory(15-21)nexum_core/src/executor/filter.rs (1)
new(53-55)nexum_core/src/catalog/mod.rs (1)
new(18-20)nexum_core/src/sql/parser.rs (1)
assignments(72-84)nexum_core/src/sql/types.rs (1)
data_type(23-31)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Rust benchmarks
- GitHub Check: Python tests
🔇 Additional comments (8)
nexum_core/src/storage/engine.rs (2)
41-49: LGTM - Clean atomic batch write implementation.The
batch_setmethod correctly uses sled'sBatchAPI and follows the same flush pattern asset(). This properly addresses the atomicity requirement for UPDATE operations.Minor consideration: You could add an early return for empty operations to avoid an unnecessary
apply_batchcall, but this is optional since sled handles empty batches gracefully.
119-135: Good test coverage for batch operations.The test verifies basic batch insertion and retrieval. Consider adding an edge case test for empty batch operations to ensure no errors occur.
nexum_core/src/sql/parser.rs (1)
64-93: LGTM - UPDATE parsing follows established patterns.The implementation correctly:
- Extracts table name
- Maps assignments using
convert_exprfor value conversion- Handles qualified column names via dot-joining
- Uses the same
where_clausepattern as SELECTnexum_core/src/executor/mod.rs (5)
191-201: Type checking logic is correct.The implementation properly:
- Allows
Nullvalues for any column type- Validates that non-null values match the expected column type
- Provides clear error messages on type mismatch
214-238: Good fail-fast behavior on WHERE evaluation errors.The implementation correctly aborts the entire operation if WHERE clause evaluation fails for any row, ensuring no partial updates occur. This maintains consistency.
309-312: LGTM - Consistent enum variant definition.The
Updatedvariant follows the same pattern asInserted, providing the table name and affected row count.
377-470: Comprehensive test with proper verification.Good test structure: creates table, inserts data, performs update with WHERE clause, and verifies both the row count and actual data changes. The approach of parsing a WHERE clause from SQL is pragmatic for testing.
551-617: Good coverage for UPDATE without WHERE clause.This test properly validates the "update all rows" behavior and verifies that all rows received the new value.
- Replace .unwrap() with proper error handling for serde_json::to_vec() - Fail early if any row serialization fails before applying batch - Maintain atomicity guarantee by preventing partial updates on serialization errors - Add descriptive error message for serialization failures Addresses CodeRabbit feedback on potential panic in batch operation.
aviralgarg05
left a comment
aviralgarg05
left a comment
There was a problem hiding this comment.
@sshekhar563 Mention the issue it solves
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
nexum_core/src/executor/mod.rs (2)
492-606: Fix test syntax errors: duplicate and conflicting statements.The test contains duplicate variable declarations and conflicting code:
- Lines 499-500: Duplicate
namefield inStatement::CreateTable- Lines 516-517: Duplicate
tablefield inStatement::Insert- Lines 562-563: Conflicting statement types (
selectvsdelete)- Lines 587-602: test logic expects 3 rows and searches for updated row, but line 602 expects only 2 rows
These conflicts will cause compilation errors.
I recommend restructuring this test to either:
- Focus solely on UPDATE testing with consistent variable names (
test_updatethroughout), or- Separate UPDATE and DELETE tests into distinct test functions
As written, the test mixes UPDATE and DELETE logic in a way that cannot compile.
688-783: Fix test: duplicate and conflicting statements.Similar to the previous tests, this test contains conflicting code:
- Lines 695-705: CREATE TABLE for test_update_all (marked with ~)
- Lines 706-710: CREATE TABLE for test_delete_all (not marked with ~)
- Lines 716-723: INSERT for test_update_all
- Lines 743-746: INSERT for test_delete_all
- Lines 774-778: Verification logic for UPDATE (checking status = "completed")
- Line 779: Expects 0 rows (DELETE verification)
The test mixes UPDATE and DELETE verification logic, causing assertion failures and confusion.
This test should verify only UPDATE behavior with consistent variable names and assertions throughout.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (4)
nexum_core/src/executor/mod.rsnexum_core/src/sql/parser.rsnexum_core/src/sql/planner.rsnexum_core/src/sql/types.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
⚙️ CodeRabbit configuration file
Focus on Rust best practices, memory safety, error handling, and idiomatic code patterns.
Files:
nexum_core/src/sql/planner.rsnexum_core/src/executor/mod.rsnexum_core/src/sql/types.rsnexum_core/src/sql/parser.rs
🧬 Code graph analysis (2)
nexum_core/src/sql/planner.rs (1)
nexum_core/src/sql/parser.rs (1)
assignments(72-84)
nexum_core/src/executor/mod.rs (5)
nexum_core/src/sql/parser.rs (1)
assignments(72-84)nexum_core/src/storage/engine.rs (2)
new(10-13)memory(15-21)nexum_core/src/executor/filter.rs (1)
new(53-55)nexum_core/src/catalog/mod.rs (2)
new(18-20)serde_json(76-76)nexum_core/src/sql/types.rs (1)
data_type(23-31)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Rust benchmarks
- GitHub Check: Python tests
🔇 Additional comments (5)
nexum_core/src/executor/mod.rs (4)
250-277: LGTM: Solid assignment validation with type checking.The implementation correctly:
- Maps column names to indices with clear error messages for missing columns
- Validates type compatibility between new values and column types
- Allows
Nullas a universal placeholder (line 267-268)- Provides descriptive error messages for type mismatches
282-311: LGTM: Two-phase update with proper WHERE evaluation.Phase 1 correctly:
- Evaluates the WHERE clause per row before collecting updates
- Handles missing WHERE clause (update all rows) explicitly
- Provides clear error messages if WHERE evaluation fails
- Aborts the entire update operation on evaluation errors, preserving atomicity
This prevents partial updates if WHERE evaluation fails mid-scan.
313-328: LGTM: Atomic batch updates with proper error handling.The implementation correctly addresses previous review feedback:
- Serializes all rows first with proper error handling (lines 320-322), avoiding the previous
.unwrap()panic risk- Only applies the batch if all serializations succeed (line 327)
- Uses
storage.batch_set()for true atomicity via sled's batch API- Fails early on serialization errors to preserve atomicity guarantees
330-340: LGTM: Good user feedback for UPDATE without WHERE.Printing a message when updating all rows without a WHERE clause (lines 330-335) is helpful for preventing accidental mass updates. The
ExecutionResult::Updatedvariant properly reports the affected table and row count.nexum_core/src/sql/parser.rs (1)
297-316: Fix syntax error: missing closing brace.The test function
test_parse_update_multiple_columnsis missing its closing brace. This will cause a compilation error.🔎 Proposed fix
_ => panic!("Expected Update statement"), + } } #[test]Likely an incorrect or invalid review comment.
| #[test] | ||
| fn test_update_multiple_columns() { | ||
| fn test_delete_all_rows() { | ||
| let storage = StorageEngine::memory().unwrap(); | ||
| let executor = Executor::new(storage); | ||
|
|
||
| // Create table | ||
| let create = Statement::CreateTable { | ||
| name: "test_update_multi".to_string(), | ||
| columns: vec![ | ||
| Column { | ||
| name: "id".to_string(), | ||
| data_type: DataType::Integer, | ||
| }, | ||
| Column { | ||
| name: "name".to_string(), | ||
| data_type: DataType::Text, | ||
| }, | ||
| Column { | ||
| name: "age".to_string(), | ||
| data_type: DataType::Integer, | ||
| }, | ||
| ], | ||
| }; | ||
| executor.execute(create).unwrap(); | ||
|
|
||
| // Insert a row | ||
| let insert = Statement::Insert { | ||
| table: "test_update_multi".to_string(), | ||
| columns: vec!["id".to_string(), "name".to_string(), "age".to_string()], | ||
| values: vec![vec![ | ||
| Value::Integer(1), | ||
| Value::Text("Alice".to_string()), | ||
| Value::Integer(25), | ||
| ]], | ||
| }; | ||
| executor.execute(insert).unwrap(); | ||
|
|
||
| // Update multiple columns | ||
| let update = Statement::Update { | ||
| table: "test_update_multi".to_string(), | ||
| assignments: vec![ | ||
| ("name".to_string(), Value::Text("Alicia".to_string())), | ||
| ("age".to_string(), Value::Integer(26)), | ||
| ], | ||
| where_clause: None, | ||
| }; | ||
|
|
||
| let result = executor.execute(update).unwrap(); | ||
| match result { | ||
| ExecutionResult::Updated { rows, .. } => { | ||
| assert_eq!(rows, 1); | ||
| } | ||
| _ => panic!("Expected Updated result"), | ||
| } | ||
|
|
||
| // Verify the update | ||
| let select = Statement::Select { | ||
| table: "test_update_multi".to_string(), | ||
| columns: vec!["*".to_string()], | ||
| where_clause: None, | ||
| order_by: None, | ||
| limit: None, | ||
| }; | ||
| let result = executor.execute(select).unwrap(); | ||
| match result { | ||
| ExecutionResult::Selected { rows, .. } => { | ||
| assert_eq!(rows.len(), 1); | ||
| let row = &rows[0]; | ||
| if let Value::Text(name) = &row.values[1] { | ||
| assert_eq!(name, "Alicia"); | ||
| } | ||
| if let Value::Integer(age) = &row.values[2] { | ||
| assert_eq!(*age, 26); | ||
| } | ||
| } | ||
| _ => panic!("Expected Selected result"), | ||
| } | ||
| } |
There was a problem hiding this comment.
Fix test: incomplete function definition.
The test function test_update_multiple_columns starts on line 609 but the function name on line 610 is test_delete_all_rows(), creating a naming mismatch. Additionally, the test body contains conflicting logic:
- Lines 616-631: CREATE TABLE for test_update_multi (marked as changed)
- Lines 706-710: CREATE TABLE for test_delete_all (not marked as changed)
This creates duplicate structure definitions and compilation errors.
The test needs to be cleaned up to have consistent naming and structure.
🤖 Prompt for AI Agents
In nexum_core/src/executor/mod.rs around lines 608 to 686, the test function
declaration is inconsistent (function opens as test_update_multiple_columns but
the next line declares test_delete_all_rows), causing a malformed/incomplete
function and duplicate test/table setup; rename the inner declaration to match
test_update_multiple_columns (or remove the extra duplicate fn line), remove any
duplicated CREATE TABLE/INSERT/SELECT blocks belonging to a different test
(test_delete_all), and ensure the test has a single, correctly named fn with
matching braces so the compile-time duplicate definitions and mismatched names
are resolved.
| Ok(Statement::Update { | ||
| table: table_name, | ||
| assignments: assignment_pairs, |
There was a problem hiding this comment.
Fix incomplete Statement::Update construction.
The Statement::Update construction is missing the where_clause field (computed on line 86) and the closing braces. This will cause a compilation error.
🔎 Proposed fix
Ok(Statement::Update {
table: table_name,
assignments: assignment_pairs,
+ where_clause,
+ })
SqlStatement::Delete {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Ok(Statement::Update { | |
| table: table_name, | |
| assignments: assignment_pairs, | |
| Ok(Statement::Update { | |
| table: table_name, | |
| assignments: assignment_pairs, | |
| where_clause, | |
| }) |
🤖 Prompt for AI Agents
In nexum_core/src/sql/parser.rs around lines 88 to 90, the produced
Ok(Statement::Update { ... }) is incomplete: it omits the where_clause field
(computed on line 86) and the closing braces/parenthesis; update the
construction to include where_clause: where_clause (or simply where_clause) and
ensure the struct literal and Ok(...) are properly closed so the
Statement::Update contains table, assignments, and where_clause before
returning.
| #[test] | ||
| fn test_parse_update_single_column() { | ||
| let sql = "UPDATE users SET name = 'Bob' WHERE id = 1"; | ||
| let stmt = Parser::parse(sql).unwrap(); | ||
|
|
||
| match stmt { | ||
| Statement::Update { | ||
| table, | ||
| assignments, | ||
| where_clause, | ||
| } => { | ||
| assert_eq!(table, "users"); | ||
| assert_eq!(assignments.len(), 1); | ||
| assert_eq!(assignments[0].0, "name"); | ||
| assert!(where_clause.is_some()); | ||
| } | ||
| _ => panic!("Expected Update statement"), |
There was a problem hiding this comment.
Fix syntax error: missing closing brace.
The test function test_parse_update_single_column is missing its closing brace after the panic statement on line 280. This will cause a compilation error.
🔎 Proposed fix
_ => panic!("Expected Update statement"),
+ }
+ }
+
fn test_parse_delete_with_where() {🤖 Prompt for AI Agents
In nexum_core/src/sql/parser.rs around lines 264 to 280, the test function
test_parse_update_single_column is missing its final closing brace, causing a
syntax/compilation error; add the missing '}' to close the match arm and
function (ensure the closing brace for the match or the function is placed after
the panic! line so the function is properly terminated), then run cargo test to
verify compilation.
| #[test] | ||
| fn test_parse_update_without_where() { | ||
| let sql = "UPDATE users SET active = true"; | ||
| let stmt = Parser::parse(sql).unwrap(); | ||
|
|
||
| match stmt { | ||
| Statement::Update { | ||
| table, | ||
| assignments, | ||
| where_clause, | ||
| } => { | ||
| assert_eq!(table, "users"); | ||
| assert_eq!(assignments.len(), 1); | ||
| assert!(where_clause.is_none()); | ||
| } | ||
| _ => panic!("Expected Update statement"), | ||
| fn test_parse_delete_without_where() { |
There was a problem hiding this comment.
Fix syntax error: missing closing brace.
The test function test_parse_update_without_where is missing its closing brace. This will cause a compilation error.
🔎 Proposed fix
_ => panic!("Expected Update statement"),
+ }
+ }
+
fn test_parse_delete_without_where() {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #[test] | |
| fn test_parse_update_without_where() { | |
| let sql = "UPDATE users SET active = true"; | |
| let stmt = Parser::parse(sql).unwrap(); | |
| match stmt { | |
| Statement::Update { | |
| table, | |
| assignments, | |
| where_clause, | |
| } => { | |
| assert_eq!(table, "users"); | |
| assert_eq!(assignments.len(), 1); | |
| assert!(where_clause.is_none()); | |
| } | |
| _ => panic!("Expected Update statement"), | |
| fn test_parse_delete_without_where() { | |
| #[test] | |
| fn test_parse_update_without_where() { | |
| let sql = "UPDATE users SET active = true"; | |
| let stmt = Parser::parse(sql).unwrap(); | |
| match stmt { | |
| Statement::Update { | |
| table, | |
| assignments, | |
| where_clause, | |
| } => { | |
| assert_eq!(table, "users"); | |
| assert_eq!(assignments.len(), 1); | |
| assert!(where_clause.is_none()); | |
| } | |
| _ => panic!("Expected Update statement"), | |
| } | |
| } | |
| fn test_parse_delete_without_where() { |
🤖 Prompt for AI Agents
In nexum_core/src/sql/parser.rs around lines 318 to 334, the test function
test_parse_update_without_where is missing its closing brace which breaks
compilation; add the missing closing brace `}` directly after the match block
(before the next test fn) so the function is properly closed and ensure all
braces are balanced.
| Statement::Update { | ||
| table, | ||
| assignments, | ||
| where_clause, | ||
| } => Plan::Update { | ||
| table, | ||
| columns: assignments.iter().map(|(col, _)| col.clone()).collect(), |
There was a problem hiding this comment.
Fix syntax error: missing closing brace.
The Statement::Update match arm is incomplete — it's missing the closing brace and comma. This will cause a compilation error.
🔎 Proposed fix
Statement::Update {
table,
assignments,
where_clause,
} => Plan::Update {
table,
columns: assignments.iter().map(|(col, _)| col.clone()).collect(),
+ },
Statement::Delete {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Statement::Update { | |
| table, | |
| assignments, | |
| where_clause, | |
| } => Plan::Update { | |
| table, | |
| columns: assignments.iter().map(|(col, _)| col.clone()).collect(), | |
| Statement::Update { | |
| table, | |
| assignments, | |
| where_clause, | |
| } => Plan::Update { | |
| table, | |
| columns: assignments.iter().map(|(col, _)| col.clone()).collect(), | |
| }, |
🤖 Prompt for AI Agents
In nexum_core/src/sql/planner.rs around lines 46 to 52, the match arm for
Statement::Update is missing its closing brace and trailing comma, causing a
syntax error; add the missing right brace to close the Plan::Update struct
construction and add the trailing comma to terminate the match arm properly
(ensure the parentheses/braces balance and the match expression compiles).
| Update { | ||
| table: String, | ||
| assignments: Vec<(String, Value)>, |
There was a problem hiding this comment.
Missing where_clause field and closing brace.
The Update variant is incomplete. The executor (in nexum_core/src/executor/mod.rs at line 241) destructures a where_clause field from Statement::Update, but this field is not present in the enum definition. Additionally, the variant is missing its closing brace and comma.
🔎 Proposed fix
Update {
table: String,
assignments: Vec<(String, Value)>,
+ where_clause: Option<Box<Expr>>,
+ },
Delete {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Update { | |
| table: String, | |
| assignments: Vec<(String, Value)>, | |
| Update { | |
| table: String, | |
| assignments: Vec<(String, Value)>, | |
| where_clause: Option<Box<Expr>>, | |
| }, | |
| Delete { |
🤖 Prompt for AI Agents
In nexum_core/src/sql/types.rs around lines 70–72, the Statement::Update enum
variant is incomplete: add a where_clause field to the Update variant (use the
exact type the executor expects where it destructures Statement::Update in
nexum_core/src/executor/mod.rs at line 241), then close the variant with the
missing closing brace and trailing comma so the enum compiles and matches the
executor's pattern.
2 participants
Summary
Implements SQL UPDATE statement support to allow users to modify existing rows in tables.
Changes
UPDATE table SET col = val, ... WHERE ...syntaxUpdatevariant toStatementenum with table, assignments, and where_clause fieldsUpdatevariant toPlanenumFeatures
Testing
Added comprehensive unit tests for:
Example Usage