Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error querying fields starting with special characters #808

Closed
thelibrarian opened this issue Sep 30, 2024 · 2 comments · Fixed by #812
Closed

Error querying fields starting with special characters #808

thelibrarian opened this issue Sep 30, 2024 · 2 comments · Fixed by #812

Comments

@thelibrarian
Copy link

thelibrarian commented Sep 30, 2024

Hi, as of Dyanmoid 3.10.0, with the merge of #655, Dynamoid no longer works with fields that start with "special" characters such as underscores in where conditions. It may also be failing with fields that contain special characters such as full stops and dashes anywhere in the field name. These names should be accounted for with the use of expression attribute names.

These queries have long worked with Dynamoid, and still work with 3.9.0, but have stopped working as of 3.10.0.

Error message from aws-sdk-dynamodb:

Invalid KeyConditionExpression: Syntax error; token: "_", near: "AND _sortKey"
@andrykonchin
Copy link
Member

andrykonchin commented Sep 30, 2024

Thank you for reporting the issue. Will work on it.

The simplest options seem to be either:

  • using placeholders for all the attribute names, not only for the reserved words
  • or additionally use placeholders for names that contain . and - or start with _/#

@thelibrarian thelibrarian changed the title Error querying fields starting with "special characters" Error querying fields starting with special characters Oct 1, 2024
@thelibrarian
Copy link
Author

I agree, and both approaches have their plusses and minuses. Using expression attribute names for all attributes is probably the safest, but may make queries run a little slower. Checking for reserved names and special characters and using expression attribute names for only those cases may make the query slightly more efficient but adds the overhead of maintaining that list and the possibility of missing some cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants