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?
Julian
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:
storage:
entities:
- name: example
attributes:
createdAt:
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.
Regards,
Rakesh
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 ?
Regards,
Rakesh
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.
Julian
2 Likes