Describe the bug
DynamoDB rejects begins_with(path, value) up front when the value isn't a string or binary. ExtendDB only checks this during row evaluation (added in #72, closed #65), so on a Scan or Query that doesn't match any rows, the check never runs and the request succeeds.
When the filter does evaluate against a row, the check fires but reports Invalid ConditionExpression: ... instead of Invalid FilterExpression: ... - the same FilterExpression labelling issue fixed for redundant parentheses in #130 / #131.
PutItem/UpdateItem/DeleteItem always evaluate the expression, so ConditionExpression isn't affected.
To Reproduce
- Create an empty table with
pk (S).
- Scan with
FilterExpression begins_with(#a, :n), #a -> pk, :n -> {N:"1"}. Accepted, should be rejected.
- Put an item with
pk set and re-run. Rejected, but labelled Invalid ConditionExpression: ....
Expected behavior
Both rejected up front with ValidationException. Same message body as #72, with the Invalid FilterExpression: prefix.
Environment
- ExtendDB version: current
main
- Deployment method: source
Checklist
Notes
Happy to tackle this, but the fix cuts across the evaluator and the handlers, so worth a steer on the approach before I open a PR.
Describe the bug
DynamoDB rejects
begins_with(path, value)up front when the value isn't a string or binary. ExtendDB only checks this during row evaluation (added in #72, closed #65), so on a Scan or Query that doesn't match any rows, the check never runs and the request succeeds.When the filter does evaluate against a row, the check fires but reports
Invalid ConditionExpression: ...instead ofInvalid FilterExpression: ...- the sameFilterExpressionlabelling issue fixed for redundant parentheses in #130 / #131.PutItem/UpdateItem/DeleteItem always evaluate the expression, so
ConditionExpressionisn't affected.To Reproduce
pk(S).FilterExpressionbegins_with(#a, :n),#a->pk,:n->{N:"1"}. Accepted, should be rejected.pkset and re-run. Rejected, but labelledInvalid ConditionExpression: ....Expected behavior
Both rejected up front with
ValidationException. Same message body as #72, with theInvalid FilterExpression:prefix.Environment
mainChecklist
mainNotes
Happy to tackle this, but the fix cuts across the evaluator and the handlers, so worth a steer on the approach before I open a PR.