K
Kysely

help

Property "values" missing when Inspecting InsertQuery ValuesNode

KNKristian Notari2/20/2023
I'm having some troubles upgrading from 0.22.0 to 0.23.4, because I have a custom plugin which gets some columns as input for each database table and prevent any other column to be used as the target of an InsertQuery (this way I can silently pass { id: 42, username: "John", nonExistingColumn: "error at runtime" } as an insert value for my user table without worrying about excessive properties in the values. I have overriden the:
protected override transformInsertQuery(_node: InsertQueryNode): InsertQueryNode
protected override transformInsertQuery(_node: InsertQueryNode): InsertQueryNode
and before the upgrade I was checking if my insert query values are actual values I need to filter to remove values for non existing columns but right now I have this error saying there's no values property inside the values node:
const newValues = node.values?.kind === `ValuesNode` ? transformValues(node.values) : ...
const newValues = node.values?.kind === `ValuesNode` ? transformValues(node.values) : ...
This is due to the node.values being a OperationNode which only has:
export interface OperationNode {
readonly kind: OperationNodeKind;
}
export interface OperationNode {
readonly kind: OperationNodeKind;
}
There used to be a ValuesNode instead, after checking for its kind "ValuesNode". But now it's just an OperationNode and I can't access values directly.
export interface ValuesNode extends OperationNode {
readonly kind: 'ValuesNode';
readonly values: ReadonlyArray<ValuesItemNode>;
}
export interface ValuesNode extends OperationNode {
readonly kind: 'ValuesNode';
readonly values: ReadonlyArray<ValuesItemNode>;
}
Do you know how to solve?
Kkoskimas2/21/2023
You can use the ValuesNode.is function for the check. Then you'll have the correct type.
KNKristian Notari2/21/2023
Ok so basically there has been a change where the nodes are considered simple "OperationNodes" and then you have to check if something is something by a guard specific for each node you'd like to check for, even if the type is not present in the target node types. I mean, it's there string-wise in the "kind" property, but that's not a discriminant type-wise, you need the guard now. Is that correct?
Kkoskimas2/21/2023
There have been changes from explicit node type unions to OperationNode in places where the node type can be a large number of types. Listing them all as a union no longer made sense. If we defined OperationNode as the union of all possible nodes, then a simple node.kind === Something would work as a guard. Currently OperationNode is defined as { kind: OperationNodeKind }. But it's been like this from the beginning. The only thing that's changed is widening of some node types from union of possibilities to OperationNode.
KNKristian Notari2/21/2023
yeah ok so using the guard of the specific node you need is the only option but there's nothing preventing me from using another guard, one of a node which is not listed in the kind of nodes available in such OperationNode (if this case exists at all), right?

Looking for more? Join the community!