aws / aws-appsync-community

The AWS AppSync community
https://aws.amazon.com/appsync
Apache License 2.0
506 stars 32 forks source link

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

Open janejjshen opened 5 years ago

janejjshen commented 5 years ago

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 commented 5 years ago

Thanks - we've added this to our backlog.

lcorneliussen commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

Nice! Thank you very much for helping out.

asyschikov commented 4 years ago

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

dtelaroli commented 4 years ago

+1 also for DynamoDB types as BigDecimal and BigInteger

veloware commented 4 years ago

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

loolooii commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ilovejs commented 3 years ago

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

VincentGaoHJ commented 3 years ago

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

greg-hornby-roam commented 3 years ago

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

Would love to see this list @AaronHarris

AlbertoSinigaglia commented 3 years ago

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 commented 2 years ago

help?

KyleKotowick commented 2 years ago

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 commented 2 years ago

Bumping this as our team needs the Long type

Simon-PumpAndUp commented 2 years ago

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

adilusman51 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@AaronHarris would like to see the list

joekendal commented 2 years ago

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

joekendal commented 2 years ago

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

joekendal commented 2 years ago

Issue can be closed

zirkelc commented 2 years ago

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.