Nitrite/Java: why did NitriteId move from long to String in 4.x?

[leoger]

I've been profiling my application recently and I see that a lot of Nitrite's query time is spent just in sorting/comparing document IDs, and that the largest chunk of that time is spent in Long.parseLong(String) converting the underlying "_id" value into a number, doing one comparison, and then throwing it away.

I went through the code and tried to find all of the ways that a NitriteId object can be created. It looks like the library does not allow any String value that fails to parse as a long, anyway.

So my question is: what was the primary motivation for moving from long to String as part of the major version move? Are there other benefits? Is it to do with serialization to/from one of the persistence formats?

Thanks,
Leo

[anidotnet]

The main reason was portability of data. Nitrite database is implemented in other languages also - nitrite-flutter is there and nitrite-rust is in development. nitrite for javascript is also in the future plan.

Now languages like javascript does not support 64bit integers, but we can very well use a document created by nitrite-java in nitrite-javascript if we represents NitriteId as a string.

[leoger]

Interesting... yeah, that makes sense. Thank you!