fix: report successful zero-column Cypher statements as success - #10
Merged
Conversation
…error (#6) ladybug.cypher() is declared RETURNS SETOF record, so callers must supply a column definition list. Statements that legitimately return zero columns -- a data CREATE/MERGE/DELETE without RETURN, or a CALL of a void procedure -- execute successfully in Ladybug and then fail the column-count check in ladybug_bridge_execute_collect() (and the sibling ladybug_bridge_fill_tuplestore_from_query()): ERROR: ladybug: failed to execute cypher via Ladybug engine DETAIL: ladybug: column count mismatch: query returns 0 columns, expected 1 The side effect has already landed, so the caller sees an error for a write that in fact succeeded; an autocommit retry would double-apply it (or fail on a duplicate key, surfacing as yet another error). liblbug reports such statements as success=true with num_columns=0 and no rows-changed count exposed via the C API, so synthesize a result instead of failing: - When the caller supplied the conventional single-TEXT status shape ("AS t(ok text)"), return one row carrying "OK" so the caller can confirm the command completed. - Otherwise, return an honest empty result set (0 rows), not a false failure. Genuine column-count mismatches (non-zero, wrong count) still raise the same error as before. Add an issue #6 regression test that runs the full sequence in one backend against a dedicated store: CREATE NODE TABLE (DDL, status column -- already fine), data CREATE (0 columns -> "OK"), MERGE (0 columns, int column list -> count 0, not error), then MATCH confirming both writes landed. Fixes #6.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes: #6
ladybug.cypher() is declared RETURNS SETOF record, so callers must supply a column definition list. Statements that legitimately return zero columns -- a data CREATE/MERGE/DELETE without RETURN, or a CALL of a void procedure -- execute successfully in Ladybug and then fail the column-count check in ladybug_bridge_execute_collect() (and the sibling ladybug_bridge_fill_tuplestore_from_query()):
ERROR: ladybug: failed to execute cypher via Ladybug engine
DETAIL: ladybug: column count mismatch: query returns 0 columns, expected 1
The side effect has already landed, so the caller sees an error for a write that in fact succeeded; an autocommit retry would double-apply it (or fail on a duplicate key, surfacing as yet another error).
liblbug reports such statements as success=true with num_columns=0 and no rows-changed count exposed via the C API, so synthesize a result instead of failing:
Genuine column-count mismatches (non-zero, wrong count) still raise the same error as before.
Add an issue #6 regression test that runs the full sequence in one backend against a dedicated store: CREATE NODE TABLE (DDL, status column -- already fine), data CREATE (0 columns -> "OK"), MERGE (0 columns, int column list -> count 0, not error), then MATCH confirming both writes landed.