Is there a way to accept a DatabasePool and opt out of interceptors (use-case: writing slonik adapter for a library -- lucia auth)

[firxworx]

Background

I wrote a 'NodeSlonikAdapter' internally for a project for the increasingly popular https://lucia-auth.com/ library. In short it helps devs implement session auth with best-practices and without as many security footguns vs. if they were to DIY auth.

I would love to submit it to the Lucia Auth project as an adapter however to generalize my solution for public release I am faced with the problem of how to accommodate slonik's flexibility.

I based the code on other adapters in https://github.com/lucia-auth/lucia/tree/main/packages/adapter-postgresql which cover pg, postgres, and @neondatabase/serverless (note: other adapters exist for drizzle, prisma, and many more).

In an app using Lucia one creates an instance of Lucia and passes it the adapter as first argument so it can interface with the persistence store. Adapters then implement methods like getUserSessions(), deleteSession(), etc.

Question Setup

I want the adapter to accept the app's slonik DatabasePool instance because I want queries from the adapter to have the same configuration as the rest of the app and use the same pool. This could be very important for everything from logging to timeouts to maximumPoolSize (which might be 1 for serverless function environments such as AWS Lambda or many for others), etc.

(Please let me know if I am off-base in my approach or understanding here!)

The issue is if I accept any slonik DatabasePool I don't know what kind of field transformation interceptors, type parser interceptors, etc. are in play nor what they might do to impact the results of a query to the database.

🙋🙋 The Question 🙋🙋

Is there a way to be given a DatabasePool instance and execute a query that's clean of any interference from interceptors that might interfere with a database adapter (such as a transformation interceptor) but keep others that might be of importance (such as for logging)?

Idk this might be a question for the mighty @gajus :D

What I Already Handle

Since I don't know the answer I already made the adapter somewhat flexible:

• The constructor accepts IdentifierSqlToken's for user + session table so they are received in a slonik-friendly way
• I am handling cases of date fields e.g. expired_at being anything from a JS timestamp to a string (ISO) to a Date.
• I am conditionally handling if a field transformation interceptor is converting snake_case fields to camelCase in results or not (expired_at vs. expiredAt).

There are other libraries and tools that take a similar approach to Lucia and I think it would be easier and more straightforward to use slonik with them if there was a good way for them to have a predictable query result when writing an adapter like this.

It would also make writing things like adapters simpler to write and test and more robust overall because there wouldn't be so many unknown "what-if's".

Is my existing implementation flexible enough or are there other likely use-cases for interceptors that I should also handle?

Thank-you slonik community!