Make DB add/remove more flexible

[brianru]

The following code restricts the accepted query params to graph-uri. That is the only supported param, at the moment. But the inflexibility means each new param requires a stardog.js change. Here is a Stardog issue for a new param: https://github.com/stardog-union/stardog/issues/7816

stardog.js/lib/db/main.js

Lines 17 to 20 in f5f4072

	const queryParams = {};
	if (params.graphUri) {
	queryParams['graph-uri'] = params.graphUri;
	}

[jmrog]

The following code restricts the accepted query params to graph-uri. That is the only supported param, at the moment. But the inflexibility means each new param requires a stardog.js change. Here is a Stardog issue for a new param: stardog-union/stardog#7816

stardog.js/lib/db/main.js

Lines 17 to 20 in f5f4072

	const queryParams = {};
	if (params.graphUri) {
	queryParams['graph-uri'] = params.graphUri;
	}

This is a good point, but flexibility also has costs. In the v2-typescript branch, I was considering making it so that the types of the params would be inferred, so that consumers of stardog.js could know which params are accepted and which are not (via types/diagnostics). Sounds like maybe you wouldn't like that?

[jmrog]

Example: https://github.com/stardog-union/stardog.js/blob/v2-typescript/lib/db/main.ts#L26

Currently, TypeScript can flag errors when you supply params that are unexpected. Does that seem too inconvenient to be of benefit? It's pretty nice to not have to look at another codebase when writing code consuming stardog.js.

[brianru]

Am I wrong to think that a user of stardog.js could then ignore the error? Or, could the type simply be open to other stuff so it validates known params but doesn't restrict the user from using others?

[brianru]

For this issue...I really just wanted to flag that at some point support for removeAll will have to be added.

[jmrog]

Am I wrong to think that a user of stardog.js could then ignore the error? Or, could the type simply be open to other stuff so it validates known params but doesn't restrict the user from using others?

Yeah, something along these lines seems reasonable.

[brianru]

We sit on different sides of the flexibility / dev experience fence :)

[jmrog]

Let's wait and see (for now, at least) whether a user of stardog.js (other than ourselves) wants this.