Conversation
| (<T extends ArrayConstructable> | ||
| (entityType: T, projection?: Projection<QLExtensions<SingularInstanceType<T>>>) | ||
| => Awaitable<SELECT<SingularInstanceType<T>, SELECT_one>, SingularInstanceType<T> | null>) | ||
| => Awaitable<SELECT<SingularInstanceType<T>, SELECT_one>, SingularInstanceType<T> | null | undefined>) |
There was a problem hiding this comment.
are there actually instances in which null is returned, or should we replace all instances of null with undefined?
There was a problem hiding this comment.
I don't know of any but at the least the runtime doesn't make the assumption that only undefined is allowed.
There was a problem hiding this comment.
🤔 I mean... SELECT null; is valid SQL. Although I wouldn't know how to do this exact query through our fluent API. I think the null type is currently there to express "nothing found". If this is supposed to be done through undefined, then we can fully replace it imho.
There was a problem hiding this comment.
What I also wanted to express in the comment of the issue is that also plugins can implement services that support the query language. In these cases, it's not in our control what the service will return for SELECT.one. Therefore, I thought accepting null and undefined is more safe.
There was a problem hiding this comment.
I see. I think we should stick with what our default logic dictates, or else we'd have to resort to any in all cases, as we'd always have to expect plugins to return something unexpected.
2 participants
No description provided.