-
Notifications
You must be signed in to change notification settings - Fork 79
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
@searchable generated DynamoDB-to-ES trigger converts JSON integer to decimal. #371
Comments
Elastic search infers types of indexes based on the content i finds and not based on the types that are defined by the schema. I am marking this as an enhancement and adding this to our backlog. |
I am experiencing this problem with the field _lastChangeAt used in conflict resolution (I think?) the error I get is:
this is a straightforward @searchable directive on an api with conflict resolution (nothing special or custom going on) I could probably put the mapping for the field in kibana before the index is created but this seems like a pretty big bug?? |
Well, I used an UGLY method to suppress this exception. If you don't need the '_lastChangedAt' field (which is added by amplify framework by default), you can try to override this value to 0 (or any other integer less than MAX_LONG), because ES(Elasticsearch) will convert field type to float automatically if it is larger than the max number of 'long' type. I tried to created a type mapping manually first on AWS ES and set '_lastChangedAt' to 'long' type, but it didn't work, ES will ignore your type mapping if the value of field exceeds MAX_LONG and still convert it to float automatically :( So, I wrote a pipeline on AWS ES using Kibana (pre-installed by AWS) like this (pipeline is an interceptor/AOP implementation for ES)
And then, invoke your pipeline by overwriting your default AWS Lambda trigger (which is created by amplify automatically)
Change it to:
All done. |
@DaZhang1994 Interesting. I haven't had a chance to try solving this yet as I have other more pressing issues in my current project but I may need to do this so thanks! As a matter of interest when you did the custom type mapping did you try "date" formate instead of "long"? I have no idea if it works but I was going to try this. |
I tried, but none of them worked. (long, int, date, none worked). But I found another way to solve this problem by checking AWS lambda log.
The problem is '_lastChangedAt': 1593996144640.0, which means AWS default lambda function (or their DynamoDB deserialization libraries) convert _lastChangedAt from Integer to a Float type. We just need to convert it back by modifying the default lambda function. After this line
Add this (just convert it from float to int using Python)
Tested and it worked without exception now. |
@yuth is there an ETA on this? |
I've submitted a PR which I think should fix this for all timestamp fields. Hopefully it will get some love from the amplify team. EDIT: Closed this PR but then reopened it as I fixed the bug I found |
Describe the bug
A clear and concise description of what the bug is.
Having AWS custom scalar type timestamp fields (or integer types) in a type marked
@model
and@searchable
To Reproduce
Steps to reproduce the behavior:
amplify push
Dynamo New Image event json, is okay
But, Posting to ES turns integer number into float/double
Expected behavior
A clear and concise description of what you expected to happen.
I expect both the 'createdAtEpochSeconds' and 'version' to be indexed an integer. The
amplify codegen
resultingAPI.service.ts
generatedSearchableIntFilterInput
for these fields.The long epoch seconds
1570485257
turns into1570485257.0
, and then somehow to1.570485257E9
scientific notation string when trying to search the records. This causes downstreamsearchFoos
serialize/de-serialize issues, for example, when trying to resolve the createdAtEpochSeconds AWSTimestamp field:Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: