mumoshu

Anyone interested this topic would also be interested in the discussion at https://news.ycombinator.com/item?id=32285435. mvsqlite might be able to handle cross-database transactions in the storage layer(=mvsqlite's mvstore backed by FoundationDB's fully serializable transactions) rather than sqlite's native one so I think there should be no theoretical limit due to SQLITE_MAX_ATTACHED.

Update:

But yeah, mvsqlite as of today seems to be tied to one sqlite per mvstore so it's attaching databases to the sqlite instance is the only way to deal with multi databases. So, it will naturally be affected by SQLITE_MAX_ATTACHED.

Perhaps a potential big idea would be to have a sqlite instance per database and a "proxy" layer above sqlite instances to (1)obtain/set a global transaction ID per multi-db transaction and (2)redirect queries to each involved sqlite databse, while the serializability is guaranteed in the FoundationDB.

Versioned pages backed by content-addressed store and transactions over the page index rather than pages! That totally makes sense to me.

Before you managed to produce mvsqlite, I was wondering if it is possible to rebase https://github.com/dolthub/dolt content-addressed page store(implemented with ProllyTree over a standard OS FS) onto FDB, so that there will be a MySQL-compat DB with similar properties to mvsqlite where actual page updates can be done outside FDB transactions to overcome 5sec FDB limit. Apparently, you already materialized a similar idea in a more sophisticated, practical, and complete way.

Thanks a lot for clarifying and keep up the great work. Your work is totally awesome!

Awesome! I've been wishing something like FDB's record-layer w/o Java/JVM and this has a lot of potential.

I have a question though- How does it handle conflicts within a sqlite DB and among multiple sqlite DBs?

I believe FDB maintains strict serializability by detecting conflicts among concurrent transactions by checking conflict ranges.

I read the doc and the mvstore code and perhaps it's working by writing the deltas of changed pages with the read version obtained at the sqlite transaction creation?

If that's the case, I'm still unsure what you added to the conflict ranges other than the deltas of the pages. To make it actually serializable, you'd need to add conflict ranges for all the pages that are `select`ed within the sqlite transaction?