Open janejjshen opened 5 years ago
Thanks - we've added this to our backlog.
Hi. I'm pretty new to AppSync; now trying to access some dynamodb resources with dates in them (saved with createdAt: Date.now())
As an alternative it would be great to see, how I can transform the ticks-based dates in dynamodb to a AWSDateTime in my gql query response.
You can use the AWSTimestamp scalar type. I have been happily using it since the timestamp is the only use case I had to represent long data types.
https://docs.aws.amazon.com/appsync/latest/devguide/scalars.html The AWSTimestamp scalar type represents the number of seconds that have elapsed since 1970-01-01T00:00Z. Timestamps are serialized and deserialized as numbers. Negative values are also accepted and these represent the number of seconds till 1970-01-01T00:00Z.
@janejjshen "The AWSTimestamp scalar type represents the number of seconds " What about if you also want milliseconds? It seems it is just an integer https://github.com/aws-amplify/amplify-cli/search?q=AWSTimestamp&unscoped_q=AWSTimestamp Thanks.
Nice! Thank you very much for helping out.
How is AWSTimestamp a fix here, I don't get it. I am still looking for the Long type for large integer numbers.
+1 also for DynamoDB types as BigDecimal and BigInteger
+1 I am storing date/time as a unix timestamp so I can use TTL (TimeToLive) but its too big for Int :/
Any update on this? This is essential for our project as we are saving numbers in the billions and storing as a String is very ugly.
You can use the Long scalar by prepending scalar Long
to your schema, and using the Long. This is not documented (or supported), but I verified that this works as of 2020-07-01. I have an unofficial list of types I add to my AppSync schemas.
@AaronHarris Thanks for your help, I have used your solution and it works. Kindly also share other types
nano second overflow normal integer range. Int or previous fix wont not work.. need new types
Previous bypass methods won't work for me,,, need new type of Long.
I have an unofficial list of types I add to my AppSync schemas.
Would love to see this list @AaronHarris
You can use the Long scalar by prepending
scalar Long
to your schema, and using the Long. This is not documented (or supported), but I verified that this works as of 2020-07-01. I have an unofficial list of types I add to my AppSync schemas.
Hi, thank you for your answer, I've applied this to a Model Condition Input, by adding the scalar Long
at the beginning, and then creating:
input ModelLongInput {
ne: Long
eq: Long
le: Long
lt: Long
ge: Long
gt: Long
between: [Long]
attributeExists: Boolean
attributeType: ModelAttributeTypes
}
and in the condition, in the field I want to be Long, I've updated the type to be ModelLongInput
... however, whenever I try to make a query with that field using gt
I get:
GraphQLResponse.Error{message='Variable 'gt' has an invalid value. Expected type 'Int' but was 'Long'.', locations='[GraphQLLocation{line='1', column='19'}]', path='null', extensions='null'}
Any idea? how much does AppSync to apply edit to the Schema to the actual API?
help?
Thanks - we've added this to our backlog.
@appwiz Has this made any progress up the backlog in the last 3 years? Lack of 64-bit support is a pretty major limitation in 2022.
Bumping this as our team needs the Long type
Please act on this urgently, I must use S2 and it requires 62int for the geohash.
Also, manually adding scalar Long
give error that LongInput
is required and push fails, sample given below
scalar Long
type DataSet @model {
id: String!
longNumber: Long
}
We use a Timescale Database (postgres extension) which creates the numeric type which will end up as Long in the returned data. This blocks the usage of a correct and precise datatype for monetary calculations.
We need to be able to use the undocumented Long type in a supported (aws-cdk, cloudformation) way. Manually adjusting the Schema is a workaround that does not work at scale.
First I thought this "aws-appsync-community" repo might not be the right place, but as @appwiz stated they added it to a backlog this indicates it is the right place.
Can anyone official speak to the fact that this repository does not seem to be maintained properly? Tags are not set on the issues, this is issue is number 21 and has not been addressed and last commit seems a years ago.
@appwiz I think this repository should be shut down (readonly) if no one cares. I dont want to be rude, but most of us are paying customers and this needs to be seen in a corporate environment.
@AaronHarris would like to see the list
This is working as of 2022, no need to add scalar Long
to schema
It does need to be updated in the AppSync docs to reflect this though
Issue can be closed
AppSync/Amplify doesn't support JavaScripts BigInt
data type: https://github.com/aws-amplify/amplify-category-api/issues/733
Don't know exactly if it's related to AppSync or Amplify.
DynamoDB's "Number" type supports large numbers that can be represented with Long.
From the docs https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html:
So if we are getting data from a DynamoDB table via AppSync, if there's a field that is of a "Long" type, AppSync should support a corresponding data type that can parse and serialize the data properly, instead of throwing an error.