Dynoxide 0.11.1: four conformance fixes
Dynoxide 0.11.1 is a small patch. Four fixes, all the same shape: spots where the engine evaluated a condition expression or validated a number slightly differently from real DynamoDB. No new features - just drift the conformance suite turned up, most of it checked back against real AWS before I closed it.
- Map and list equality in a
ConditionExpression. Comparing anMorLattribute with=always reported not-equal, and<>always equal, whatever the values held. There was no comparison arm for document types, so they fell through to the not-equal default. They now compare deeply - maps order-independently, lists element-wise in order.IN,BETWEENandcontainsover documents ran the same path, so they're fixed too. (#103) - Nesting past the 32-level limit. Expression values nested deeper than DynamoDB's 32 levels were accepted and evaluated; they're now rejected up front with the
ValidationExceptionAWS returns, on every path that takes expression values - PutItem, UpdateItem, DeleteItem, Query, Scan, TransactWriteItems. The stored-item check was a level too lenient as well, and carried a non-AWS message - both now match, confirmed against eu-west-2. (#110) - Number-set equality at full precision. Set comparison parsed each member to an
f64, so two sets that differed only past ~15 significant digits read as equal. It now uses the canonical numeric form, the same way duplicate members are already caught on write, and covers number sets nested inside a map or list. (#111) - A leading
+on numbers. Real DynamoDB accepts+5,+1.5and+1e2and stores them normalised (+5reads back as5); dynoxide was rejecting them. The validator now takes exactly DynamoDB's numeric grammar, which also tightened a few forms that used to slip through the other way -1+2,1.2.3, a digitless exponent, and stray whitespace like" 5". (#109)
The release is on GitHub. If you hit something that doesn't match DynamoDB, that's a bug report worth filing - it's exactly what the suite is there to catch.