UnQLite Users Forum

Ordering of keys?

append delete cleifer

I have noticed some inconsistency in the order of keys returned when iterating through the database. Particularly, I notice the ordering is one way when I first store data, then when I close and reopen the database, the ordering is different (reversed, typically).

I've noticed this with both file and in-memory databases.

Is the ordering stable or predictable? What's going on here?

Reply RSS


append delete #1. chm

Hi Charles,

This depends on the underlying KV storage engine used, and since the in-memory and the on-disk datastore uses a nearly identical HashTable algorithms, entries are returned (I mean here, when you use the cursor iterators interfaces) in a way similar to a LIFO stack.

The difference you see when entries are returned in a fresh new database is that they are kept in memory (The cache manager) in a way similar to a FIFO stack (unlike the on-disk LIFO and a little more complex in fact) before they are flushed to disk. That's the reason why you see difference in a newly created database.

Note that if the B+Tree KV storage were used, entries will be returned the same way (new or already created DB) using whatever sorting function were used.

Hope this helps,

append delete #2. cleifer

How can I indicate that I want to use the B+Tree?

append delete #3. cleifer

I should clarify that I tried `unqlite_config()` using the UNQLITE_CONFIG_KV_ENGINE verb and passing 'btree'.

append delete #4. chm

Yes, this the correct way to use the B+tree KV store, but this storage engine is not provided in the current public release of UnQLite.

append delete #5. Johannes

You can use the Larry c-code for btree on disk in combination with unqlite

append delete #6. flanhard

@Johannes Any link? Thanks

append delete #7. asdf

What's the Larry c-code?

append delete #8. Tony Di Croce

How do we use a b-tree storage engine? Is it included in the paid for amalgamation?

append delete #9. chm

@Tony Di Croce,

B+Tree storage engine is not yet to be released within the amalgamation.

append delete #10. Steven

Is there any particular estimated timeframe for completion of the B+ tree storage engine?

:: @Steven added on 07 Mar ’18 · 23:49

I guess that I should also ask if you would consider financially sponsored development of the B+ tree storage engine, to move it up the priority list?

append delete #11. chm


Thank you Steven for your proposal. Since the project is open source, we do accept sponsored development like we did with the compression & encryption (CERD) extension.

Contact chm@symisc.net or devel@symisc.net if you plan to do so for the B+tree storage engine.


(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: chm_at_symisc, devel_at_symisc