Are there any plans for supporting a true BigInt/HugeInt data type (i.e. without any length restriction) in the near future?
----- Original Message ----- From: Simon Slavin <slav...@bigfraud.org> To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Sent: Wednesday, May 2, 2018, 19:04:33 Subject: [sqlite] How to Handle BigInt On 2 May 2018, at 5:22pm, dmp <da...@dandymadeproductions.com> wrote: > Since I'm using Java and JDBC I was retrieving numeric fields in PostgreSQL > with getString(), handles all, then using Integer.parseInt(stringValue) for > BigInts in storing to SQLite. > There lies the problem since BigInt values were exceeding the range of > Java Integer. My original solution was to store these as strings, will now > just use Long.parseLong(stringValue) and store has SQLite Integers > properly. Also note that if you store your numbers as strings, indexes on those values will order them as strings. In other words, searching and sorting will work incorrectly. It should be possible to get your numbers from a Java numeric variable to a database numeric value without passing them through a string at any point. And, of course, back out of the database into a numeric variable. If your database library does not allow this, you have a serious problem. As a solution purely about SQLite, SQLite has a "black box" type of BLOB. BLOB is used to store bytes, without putting any interpretation on those bytes. Although technically you can search and sort BLOBs, it's probably a sign of faulty thinking. If I was trying to store something in a database which I didn't want interpreted in any way, I'd use a BLOB. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users