Limits for Complex Queries integer data type

Hey there,

Has anyone encountered an issue when working with complex queries, where using the integer attribute type results in an error like 'Error: Data type for property "createdAt" is defined as "integer"' for ‘high’ numbers like timestamps, even though it works fine for lower numbers (like age or year like in the documentation)?

Is there an undocumented limit for this data type that triggers this exception, and if so, how can I address it?


1 Like

It looks like integer attributes can only store 32-bit signed integers. I don’t think this is documented anywhere.

1 Like

It seems the limit is even lower: I can not save 1,693,939,979 (current timestamp) - 32bit would mean a range from -2,147,483,648 to 2,147,483,647.

1 Like

That’s strange… Storing 1,693,939,979 is working for me with this entity definition:

    - name: example
          type: integer
storage.entity("example").set("example", { createdAt: 1693939979 });

-2,147,483,648 and 2,147,483,647 are the lowest and highest values I was able to store.

Hi @JulianWolf , Thanks for raising this.
We are looking into this, will get back to you as soon we find any information.


1 Like

Hi @JulianWolf ,
We have validated the limit for integer type and successfully stored the timestamp 1,693,939,979 as an integer. Would you kindly confirm if you are parsing the input as an integer ?


You are right @RakeshJha & @klaussner

I have made a mistake in my last post.

It is possible to persist a timestamp as seconds:

const createdAtSeconds = new Date().getTime() / 1000 // works

It is not possible to persist as milliseconds:

const createdAtSeconds = new Date().getTime() // does not work as integer 

So @klaussner is probably right with the 32bit limit.

A workaround for us is to use float, which apparently has a higher limit.

Thank you @RakeshJha, my recommendation would be to improve the docs on those limits as data migration is tedious.