Computed/derived fields in Drizzle Orm
Hi,
I am new to Drizzle, so sorry if it is a stupid question, but while picking it up, browsing the docs, etc... I noticed something missing I had normally with many other ORMs in the past: computed fields (as Prisma call them, for example as what I mean).
I don't know if I missed something, I didn't find an explanation in the introduction/philosophy of the docs... but I would like to know what the recommended path here and the stance of Drizzle on the subject (is it not implemented yet, not a desired feature because of complexity, performance, etc).
I know I can always derive these states as I need them, but It is an approach I have seen in most ORM I used, so I am curious to know why, how, and all.
3 Replies
There are currently three answers to your question:
- If you are looking for generated columns, which is a database "computed field", there is currently a PR for this and it's in the reviewing phase. #1471
- If you are looking for something generated in javascript and then sent to the database, one solution is using the
.$default() function in the column to generate what you want in javascript.
- If you need a more complex "computed field", where your generated data depends on other factors and/or columns, it's in the design phase. Take a look at discussion #1513Oh, thanks, forgot to watch issues on GitHub. Did my search here and in the docs...
- #1471: rarely had to use these. Usually, I ended up using the functionality to make raw queries and store the results in other variables. But it's nice to have... I had it in the past I think in some python ORM.
- .default() like yeah, obviously, a classic.
- #1513: I am not sure, I had it in the past, it's very powerful, but might complicates things and make them look harder than it need to be.
But very cool, if they manage to do what's proposed at the end, not just validation.
However, I was thinking about something much more simpler:
Imagine having birthday stored in your dB, you want the age of the user for some calculation (maybe health subject)... I might do the calculation X times in different pages, I might do an helper to avoid repetition, but I could have a field generated after the fetch from the dB based on the birthday field.
For more complicated fields, it allows to derive a state in a standardized way, which avoids errors made by multiple people working on the same codebase for example...
For that, you'll either need point 1 or 3.