Open danielrearden opened 4 years ago
The logic for handling normalization of keys is because ESLint may enforce id-match
rule.
The same reason does not apply for unique constraints.
In some thread it was even discussed that we should allow to override this using explicit sql.identifier
, e.g.
update(
connection,
'user',
{
[sql.identifier(['given_name'])]: 'foo'
}
);
What's the logic for needing the unique constraint to be normalized?
Beyond just consistency, it would also allow for some additional type safety when entering the unique column names:
function upsert<T extends NamedValueBindingsType> (
connection: DatabaseConnectionType,
tableName: string,
namedValueBindings: T,
inputUniqueConstraintColumnNames: ReadonlyArray<keyof T> | null = null,
inputConfiguration: UpsertConfigurationType | null = null,
): Promise<unknown>
Interesting. I like this. Will patch it up.
The column names passed in through the
uniqueConstraintColumnNames
parameter should be normalized just like the named value bindings are. In other words, if I submit{ emailAddress: 'gajus@gajus.com' }
as the value bindings, I should be able to submit['emailAddress']
as the unique constraint column. Right now, I have to normalize the name myself (i.e.['email_address']
).