Skip to content

Conversation

@himself65
Copy link
Contributor

Related: nodejs/node@d1eabcb
Related: nodejs/node#59405
Related: better-auth/better-auth#3869
Related: oven-sh/bun#22109

Nowadays, there are tons of database packages, like sqlite3, sqlite, better-sqlite, bun:sqlite... Checking the difference from them is pretty hard.
instanceof is not good, since the developer will still need to import the module, which is costly.
I think we should provide a symbol to distinguish different SQLite classes, at least nodejs could make the first step

This symbol could help with lots of duplicate properties checking, like https://github.com/kysely-org/kysely, https://github.com/knex/knex

It helps the library author to write an adapter for a different SQLite library. Right now, the library is checking the prototype method to determine whether it's node:sqlite, bun:sqlite, or better-sqlite... It was a lot of performance, and it's not stable as the API could change

https://github.com/better-auth/better-auth/blob/375e9f3ced6f3842c133f4cae689cb2a604ba94a/packages/better-auth/src/adapters/kysely-adapter/dialect.ts#L53-L109

I hope there's an easy way. like a symbol tag, to determine the user's land SQLite lib

@himself65 himself65 changed the title feat(ext/node): add sqlite-type symbol for DatabaseSync feat(ext/node): add sqlite-type symbol for DatabaseSync Aug 25, 2025
@himself65

This comment was marked as outdated.

Comment on lines +24 to +26
ObjectDefineProperty(DatabaseSync.prototype, sqliteTypeSymbol, {
__proto__: null,
value: "node:sqlite",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@littledivy is this okay, or should we do it in Rust?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea this can be done in Rust:

#[getter]
#[symbol("sqlite-type")]
fn sqlite_type(&self) -> bool {
  true
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks! let me fix it

himself65 and others added 3 commits August 25, 2025 08:23

// Returns "node:sqlite" for Node.js compatibility
#[getter]
#[symbol("sqlite-type")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@littledivy this seems to panic now... Should we fix it in deno_core and for the time being use the previous version in JS?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh we reuse the name as a Rust identifier in the macro. I think we can revert to the JS version for now @himself65. I will open a deno_core PR to fix the panic.

Copy link
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted to using a JS symbol for now. LGTM, thanks!

@bartlomieju bartlomieju enabled auto-merge (squash) September 8, 2025 21:19
@bartlomieju bartlomieju merged commit cb4207e into denoland:main Sep 8, 2025
19 checks passed
Tango992 pushed a commit to Tango992/deno that referenced this pull request Sep 24, 2025
Related:
nodejs/node@d1eabcb
Related: nodejs/node#59405
Related: better-auth/better-auth#3869
Related: oven-sh/bun#22109

Nowadays, there are tons of database packages, like sqlite3, sqlite,
better-sqlite, bun:sqlite... Checking the difference from them is pretty
hard.
instanceof is not good, since the developer will still need to import
the module, which is costly.
I think we should provide a symbol to distinguish different SQLite
classes, at least nodejs could make the first step.

---------

Signed-off-by: Alex Yang <himself65@outlook.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
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.

3 participants