Question

In my application I have stored the timestamp as an integer on each entity I save. When I then later query the database by comparing timestamps I get an error such as the following:

Error: One of the request inputs is not valid.
RequestId:3b61f705-ca01-4742-981b-6e2332029874
Time:2013-12-06T16:49:42.0282802Z

After a lot of debugging I finally found out what was going on. In my code I have the following query

    var query = azure.TableQuery
        .select()
        .from(self.tableName)
        .where('added gt ?', timestamp);

If I set timestamp to be Math.pow(2,30), everything seems fine, but increasing it to Math.pow(2,31) will give me the error. I found this behaviour somewhat strange since among the Azure Table Storage types is the Int64 type. This is essentially making use of that, and the values I have stored are certainly much bigger than an Int32.

I ended up working around this by converting the values to DateTime by throwing new Date(timestamp) everywhere, but that should have been unnecessary. Anyone come across this, and managed to save integers as integers?

Was it helpful?

Solution

The Azure Table Storage API Int64 literal must use the L suffix.

var query = new azure.TableQuery()
   .where('loginTimeMS lt ?', 1406828512316);
query._where[0]+="L";

Effectively putting the following string into the table query...

"loginTimeMS lt 1406828512316L"

Note the L at the end. This query will find entities where the property loginTimeMS is less than 1406828512316 which is an Int64.

It feels like a work around - be interested to hear if anybody has found a more elegant solution.

OTHER TIPS

So Javascript does not support "integers" in the traditional fashion. Please take a look at this answer on 64-bit integers.

All positive integers up to 2^53 can be encoded precisely. Larger integers get their least significant bits clipped. This leaves the question of how can you even represent a 64-bit integer in javascipt -- the native number data type clearly can't precisely represent a 64-bit int.

Now beyond that problem, you seem to be having an issue at the 32-bit barrier. Have you checked your version of node.js? Node for Windows comes in both 32 & 64-bit flavors.

I suspect that you may be running the 32-bit version (x86) instead of the 64-bit version (x64). That may solve part of your problem.

That stated, it won't solve the problem above as you'll eventually run into issues around 54 bits. Node.JS has several integer libraries available that you may need to employ.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top