retrieving db keys causes some keys to become invisible to subsequent lookups about unqlite-python HOT 6 CLOSED

Have you tried writing a minimal C version to verify the problem is the Python bindings?

from unqlite-python.

Yes - seems like it might be a problem with the C library itself. Posted it on the unqlite issue tracker.

from unqlite-python.

Interesting... I tried the same experiment. I used 1000 records and after a close/reopen iterate (1000), iterate again ... 976?? Wtf! Interestingly I'm double the number of records short that you are (12 -> 24).

Closing and re-opening I get my 1000 back, but I'm curious to see which keys are missing....so here are the ones that were missing:

{'key_270',
'key_271',
'key_371',
'key_390',
'key_416',
'key_417',
'key_490',
'key_516',
'key_517',
'key_531',
'key_533',
'key_534',
'key_535',
'key_536',
'key_921',
'key_922',
'key_923',
'key_933',
'key_940',
'key_941',
'key_950',
'key_951',
'key_960',
'key_970'}

I tried this twice times and got the same keys missing each time.

My conclusion at the moment? Run the fuck away from UnQLite.

from unqlite-python.

I've added a failing test-case despite the project author's suggestion that I upgrade to the latest version it is present in the 1.1.6 source amalgamation in their GH repo.

I'll keep an eye on symisc/unqlite#41 and update the bundled sources as soon as it's fixed upstream but from what I currently understand this is a library issue rather than a bindings issue.

from unqlite-python.

This is fixed in version 0.6.0. I dropped the amalgamation and am using the individual sources instead which contained the fix for the above issue.

from unqlite-python.

Thanks!

from unqlite-python.