2

I have a Stream Analytics job that converts a timestamp into a number of milliseconds since Epoch.

To do this, I use a JavaScript function that returns a bigint, using the following code:

new Date(date).getTime()

When I test this job in the Azure portal, I get the correct result, e.g.: 2018-08-29T13:01:54.0000000Z becomes 1535547714000:

enter image description here

But when I run the job and it starts storing its output in an Azure table, 1535547714000 becomes -2050577968.

I noticed that if I cast the bigint 1535547714000 into an int, I get -2050577968. So I checked the type of the column and, strangely, it's Int64:

enter image description here

TL;DR: The job outputs a bigint, the column type is bigint Int64 but somehow, somewhere in between, the value seems to be cast into an int.

How do I fix that?

Rodolphe
  • 1,689
  • 1
  • 15
  • 32

1 Answers1

1

Rodolphe. If you want to transfer data into Azure Table Storage, you have to follow the rules of it.

Based on the doc, Azure Table Storage only supports int32 and int64 type, no bigint type. So, actually there is no mysterious mechanism to convert your data type, just when the bigint data into the table, it is converted to the corresponding Int64 type.However, it supposed to be 1535547714000,no way to be converted to int.You could commit feedback to Azure to post this issue.

As a workaround, you could try to get the data and convert it into Int64 in Azure Table Storage Azure Trigger Function. Please refer to this doc.

Hope it helps you.

Jay Gong
  • 23,163
  • 2
  • 27
  • 32
  • OK but `bigint` and `Int64` are both 64-bit integers. So, like you said, there shouldn't be any conversion to 32-bit integer. Anyway, I realised that I don't really need the millisecond precision, so I updated my code and it now works as expected. Thanks! – Rodolphe Aug 31 '18 at 07:50
  • @Rodolphe sure. if you don't mind, you could adopt the answer for others' reference,thank you! – Jay Gong Aug 31 '18 at 07:56