Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SOCI can't row.get<int64_t>() even though SQlite INTEGER supports 64-bit values #1185

Open
dsjstc opened this issue Dec 10, 2024 · 3 comments

Comments

@dsjstc
Copy link

dsjstc commented Dec 10, 2024

TLDR: SQlite INTEGER supports 64 bit values, but Soci's row.get<> seems to require an int32, even though soci::into() seems to work as expected. If this is expected behaviour of row.get<>, it could benefit from being documented.

Details in this stack overflow post. MVCE here:

#include <soci/soci.h>
#include <soci/sqlite3/soci-sqlite3.h>
#include <iostream>

int main() {
    try {
        // Create an in-memory SQLite database session
        soci::session sql(soci::sqlite3, ":memory:");
        sql << "CREATE TABLE test_table (id INTEGER PRIMARY KEY, myInt INTEGER);";
        sql << "INSERT INTO test_table (myInt) VALUES (9223372036854775807);";

        // This works
        int64_t retrievedValue1;
        sql << "SELECT myInt FROM test_table WHERE id = 1", soci::into(retrievedValue1);
        std::cout << "Implicit retrieval: " << retrievedValue1 << std::endl;

        // This throws std::bad_cast (windows) or overflows int32 for a -1 (linux)
        soci::row r;
        sql << "SELECT myInt FROM test_table WHERE id = 1", soci::into(r);
        int64_t retrievedValue2 = r.get<int64_t>("myInt");
        std::cout << "Explict 64-bit retrieval: " << retrievedValue2 << std::endl;

    } catch (const std::exception& e) {
        std::cerr << "Error: " << e.what() << std::endl;
    }

    return 0;
}
@Sildra
Copy link
Contributor

Sildra commented Dec 10, 2024

https://soci.sourceforge.net/doc/master/backends/sqlite3/
Change create statement from INTEGER to bigint.

@Krzmbrzl
Copy link
Contributor

Krzmbrzl commented Jan 3, 2025

@dsjstc what version of SOCI are you using. 'cause I feel like #1127 should solve your issue, no? In other words: can the issue be reproduced when building SOCI yourself from current master?

@Krzmbrzl
Copy link
Contributor

Krzmbrzl commented Jan 7, 2025

The compile error is gone thanks to #1127 but the internal representation of SQLite integers is still wrong on SOCI's end. See #1190

@vadz This issue can be closed (imo)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants