Skip to content

PR: Feature - SQLite uuid Extension#170

Closed
LucaCappelletti94 wants to merge 17 commits intoSpxg:masterfrom
LucaCappelletti94:extension-uuid
Closed

PR: Feature - SQLite uuid Extension#170
LucaCappelletti94 wants to merge 17 commits intoSpxg:masterfrom
LucaCappelletti94:extension-uuid

Conversation

@LucaCappelletti94
Copy link
Contributor

@LucaCappelletti94 LucaCappelletti94 commented Jan 28, 2026

This PR introduces implementations of SQLite UUID extensions, specifically UUIDv4 (Random) and UUIDv7 (Time-ordered). These extensions are implemented as separate crates within the workspace (extensions/uuid4, extensions/uuid7) using sqlite-wasm-rs bindings and the native uuid crate.

This allows users to generate and manipulate RFC-9562 UUIDs directly within SQL queries in a WASM environment.

UUIDv4 (Random)

Based on the standard SQLite uuid.c API but implemented in Rust.

  • uuid(): Generates a random 36-char string.
  • uuid_str(X): Standardizes input (Blob/Text) to 36-char string.
  • uuid_blob(X): Converts input to 16-byte BLOB.
  • uuid_blob(): (Added) Generates a new random 16-byte BLOB directly.

UUIDv7 (Time-Ordered)

A new extension for timestamp-based UUIDs, providing better index locality for direct SQLite use.

  • uuid7(): Generates a time-ordered 36-char string.
  • uuid7_blob(X): Converts input to 16-byte BLOB.
  • uuid7_blob(): Generates a new time-ordered 16-byte BLOB directly.

Testing

  • Verified correct UUID version bits (v4 vs v7).
  • Generation formats (Text vs Blob).
  • Usage as DEFAULT column values in schemas.
  • Sorting/Monotonicity for UUIDv7, uniqueness for UUIDv4.
  • Round-trip conversions between String and BLOB formats.

@LucaCappelletti94 LucaCappelletti94 marked this pull request as ready for review January 28, 2026 11:06
@Spxg
Copy link
Owner

Spxg commented Jan 29, 2026

Thank you for your work. I haven't reviewed it yet, but would it be possible to put these changes in a new repository, such as extensions/sqlite-uuid?

@LucaCappelletti94
Copy link
Contributor Author

I suppose so, but how is that crate then folded into the first one at compile time? Maybe it is straightforward, I just haven't understood.

@Spxg
Copy link
Owner

Spxg commented Jan 29, 2026

@LucaCappelletti94
Copy link
Contributor Author

No ok sure, just I wasn't clear how it was compiled against sqlite. I will read more in details later.

@LucaCappelletti94
Copy link
Contributor Author

Would you prefer these extension to be in one or two crates?

@LucaCappelletti94
Copy link
Contributor Author

Just fyi, I also tried to use directly the uuid instead of using the c code, making bindings to it, but it turned into a very hard to read/debug mess of function pointers.

I will continue with the original approach of just slightly reworking the uuid extension from SQLite and using the customized version of the postgres one.

@LucaCappelletti94
Copy link
Contributor Author

Ok I managed to rewrite the whole thing solely using the uuid crate in the end, instead of adapting the original C extension code or the postgres code. This makes me much more comfortable of the correctness of the implementation.

@LucaCappelletti94
Copy link
Contributor Author

I have updated the original post to reflect the changes made.

@Spxg
Copy link
Owner

Spxg commented Jan 30, 2026

I haven't looked at the implementation in detail yet, but it seems that those C shims from sqlite-wasm-rs are no longer needed, right? Then I think this can be considered your own project, rather than contributing code to sqlite-wasm-rs.

@LucaCappelletti94
Copy link
Contributor Author

I haven't looked at the implementation in detail yet, but it seems that those C shims from sqlite-wasm-rs are no longer needed, right? Then I think this can be considered your own project, rather than contributing code to sqlite-wasm-rs.

Yes I think that as it is now, it should be rather modular.

Still, with uuid being a very standard type it is somewhat reasonable to have it here and avoid future API changes potentially breaking something. That being said, if you prefer I can fold it into a crate of my own.

@Spxg
Copy link
Owner

Spxg commented Jan 30, 2026

avoid future API changes potentially breaking something

Given that sqlite-wasm-rs is currently used by diesel and rusqlite, it now and in the future only provides SQLite C API, so it is stable.

I can fold it into a crate of my own.

Yeah, thanks for your work!

@LucaCappelletti94
Copy link
Contributor Author

Trivial question - are these extensions usable in diesel? Right now your example only shows how to load this extension in rustqlite.

@Spxg
Copy link
Owner

Spxg commented Jan 30, 2026

Adding extension is unrelated to diesel, just use sqlite_wasm_rs::sqlite3_auto_extension(xxxx).

@LucaCappelletti94
Copy link
Contributor Author

Ok! My confusion was only caused by:

use rusqlite::{ffi::sqlite3_auto_extension, Connection};

@Spxg
Copy link
Owner

Spxg commented Jan 30, 2026

yeah.. rusqlite re-exported the ffi from sqlite-wasm-rs

@LucaCappelletti94
Copy link
Contributor Author

For future reference, it is here: https://docs.rs/sqlite-wasm-uuid-rs/latest/sqlite_wasm_uuid_rs/

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

Successfully merging this pull request may close these issues.

2 participants