You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Doing this, we've discovered that even though the type being returned in the dataType function is a type well known to drizzle, the typing is lost when the query is built, eventually leading to our queries failing, since we're using the AWS Data API that receives no typeHint because of the missing typing here.
Looking at the codebase, this seems to come down to the fact that the typings are infered from the instance of the class (or alternatively from the entityKind field in the class) in
which will always return none for custom types, since the class is PgCustomColumn.
I'm not familiar enough with the codebase to tell whether the following solution would introduce other issues, but I did some brief testing modifying the prepareTyping function to something like:
What version of
drizzle-orm
are you using?0.30.1
What version of
drizzle-kit
are you using?No response
Describe the Bug
Hello.
We're using the
customType
to do simple overloads of thetoDriver
/fromDriver
methods on well known data types (e.g. uuid) using postgresql. E.g.:Doing this, we've discovered that even though the type being returned in the
dataType
function is a type well known to drizzle, the typing is lost when the query is built, eventually leading to our queries failing, since we're using theAWS Data API
that receives notypeHint
because of the missing typing here.Looking at the codebase, this seems to come down to the fact that the typings are infered from the instance of the class (or alternatively from the
entityKind
field in the class) indrizzle-orm/drizzle-orm/src/pg-core/dialect.ts
Lines 494 to 512 in bfc757f
which will always return
none
for custom types, since the class isPgCustomColumn
.I'm not familiar enough with the codebase to tell whether the following solution would introduce other issues, but I did some brief testing modifying the
prepareTyping
function to something like:to maintain the typing if it's well known. This worked successfully.
I was hoping that someone more familiar with the codebase could look into whether a solution like this would be feasible going forward?
Expected behavior
Typings to be preserved when using known data types in
customType
.Environment & setup
Postgresql.
The text was updated successfully, but these errors were encountered: