Feature request: Support for the Long datatype (64 bit integer)

[janejjshen]

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:

Number
Numbers can be positive, negative, or zero. Numbers can have up to 38 digits precision. Exceeding this results in an exception.

Positive range: 1E-130 to 9.9999999999999999999999999999999999999E+125

Negative range: -9.9999999999999999999999999999999999999E+125 to -1E-130

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.

Can't serialize value (/queryItems/LongProperty) : Expected type 'Int' but was 'Long’.

[appwiz]

Thanks - we've added this to our backlog.

[lcorneliussen]

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.

[janejjshen]

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.

[Ricardo1980]

@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.

[lcorneliussen]

Nice! Thank you very much for helping out.

[asyschikov]

How is AWSTimestamp a fix here, I don't get it. I am still looking for the Long type for large integer numbers.

[dtelaroli]

+1 also for DynamoDB types as BigDecimal and BigInteger

[veloware]

+1 I am storing date/time as a unix timestamp so I can use TTL (TimeToLive) but its too big for Int :/

[loolooii]

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.

[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.

[adilusman51]

@AaronHarris Thanks for your help, I have used your solution and it works. Kindly also share other types

[ilovejs]

nano second overflow normal integer range. Int or previous fix wont not work.. need new types

[VincentGaoHJ]

Previous bypass methods won't work for me,,, need new type of Long.

[greg-hornby-roam]

I have an unofficial list of types I add to my AppSync schemas.

Would love to see this list @AaronHarris

[AlbertoSinigaglia]

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?

[hunterhug]

help?

[KyleKotowick]

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.

[jzybert]

Bumping this as our team needs the Long type

[Simon-PumpAndUp]

Please act on this urgently, I must use S2 and it requires 62int for the geohash.

[adilusman51]

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
}

[pfried]

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.

[joekendal]

@AaronHarris would like to see the list

[joekendal]

This is working as of 2022, no need to add scalar Long to schema

[joekendal]

It does need to be updated in the AppSync docs to reflect this though

[joekendal]

Issue can be closed

[zirkelc]

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.