Using Knex directly and expected date type behaviour #5556
Replies: 2 comments 3 replies
-
Yes, this is done on purpose, dates are mapped in the ORM during result mapping (since the way the drivers do it is very inconsistent, e.g. it does not work with dates inside JSON properties, and it differs greatly among the SQL drivers). You can create your own knex instance that will map things the default way if you need it, the one the ORM creates has the date processing disabled completely. Not sure if you can reuse the same connection pool in this case, that's more of a question for knex maintainers. You could also maybe override the types mapping on a knex QB level. I would personally just map the results via Note that you shouldn't await |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick reply. So I can either:
Regarding 1: Regarding 2: For now I have gone with option 3, doing the transformation myself using the 'postgres-date' package. P.S. good to know about awaiting |
Beta Was this translation helpful? Give feedback.
-
When we use the instance of Knex which comes with MikroOrm (6.2.5), dates are no longer converted to javascript Dates but are returned as strings.
This used to work in 5.x and was handy for our use case. We use MikroOrm for mutating state and the query builder for some simple queries but we have many views and more complex queries against those are just written in sql and executed with knex.raw.
I was going to raise this as a bug but perhaps it's not something MikroOrm supports any longer as I can see that this change has been made quite deliberately.
If so I could manage my own instance of Knex but then I think i'd lose connection pooling by having 2 different instances.
Is this use case something MikroOrm supports? Any suggestions on how best to execute raw SQL and get the results I expect?
Beta Was this translation helpful? Give feedback.
All reactions