feat: add named params support

[ibilux]

Hello,

This is a work-in-progress for #91 aiming to add support for named parameters.
I’ve added tests, and they’re all passing so far. However, the current implementation is not perfect (far from it, actually), there’s definitely room for improvement.

Any feedback or suggestions for a cleaner or more efficient approach would be very welcome.

Thank you.

[DallasHoff]

sqlTag and normalizeSql should probably just be combined into one function. I'd look into replacing sqlTag in the places it is used with the normalizeSql implementation. I'd keep the sqlTag naming though.

[ibilux]

Yes, it would be better i think.

[DallasHoff]

I meant that normalizeSql should be renamed to sqlTag, and the old implementation of sqlTag should be deleted. normalizeSql can take its place.

[DallasHoff]

This is looking really good so far.

[ibilux]

This is looking really good so far.

What do you think about using BindingSpec type instead of unknown[] | Record<string, unknown> in the Statement params:

export type Statement = {
	sql: string;
	params: unknown[] | Record<string, unknown>;
};

The BindingSpec is the bind type in db.exec:

sqlocal/src/drivers/sqlite-memory-driver.ts

Line 213 in c105867

bind: statement.params,

Referenced from SQLite wasm:
https://github.com/sqlite/sqlite-wasm/blob/31e4b6e478a3f10a11b477feb08f1e54b53c791a/index.d.ts#L318

[ibilux]

• I have a updated the named parameters extraction method for all cases with more tests.
• I have add tests for the numbered positional parameters ?NNN.
• The last commit is just for testing the sqlite/wasm Bindable types (we can revert it if it's out of this PR scope).

[ibilux]

• I have a updated the named parameters extraction method for all cases with more tests.
• I have add tests for the numbered positional parameters ?NNN.
• The last commit is just for testing the sqlite/wasm Bindable types (we can revert it if it's out of this PR scope).

We can also export the normalizeNamedParams as a helper function and give the user the option to chose if he wants to use the helper function of provide a valid named parameters object:

// Use the `normalizeNamedParams` helper function
await sql('INSERT INTO groceries (name) VALUES (:name)', normalizeNamedParams({ name: 'bread' }));

// Or provide a valid binding object instead
await sql('INSERT INTO groceries (name) VALUES (:name)', { ':name': 'bread' });

This provide more flexibility, but may introduce some confusion.

[DallasHoff]

Let's not use BindingSpec or BindableValue. Simpler types will suffice.

[DallasHoff]

If you finish making changes, please feel free to request re-review or remove the draft status from the PR.

[ibilux]

Let's not use BindingSpec or BindableValue. Simpler types will suffice.

I reverted that commit.

If you finish making changes, please feel free to request re-review or remove the draft status from the PR.

Yes, it should be ready for review.

[DallasHoff]

I also left this comment last night. Did you see it and does it make sense?

[ibilux]

I also left this comment last night. Did you see it and does it make sense?

I didn't notice it. I think that would be better.

I meant that normalizeSql should be renamed to sqlTag, and the old implementation of sqlTag should be deleted. normalizeSql can take its place.

The last commit merges normalizeSql into sqlTag, now there is one entry for handling SQL queries.