Option to disable $dynamic() requirement for query building

[anthonyma94]

I've been one of the early adapters for drizzle-orm and it has been mostly a positive experience. However, the new requirement for adding $dynamic() has me thinking about whether I should really continue with such a young library.

About 80% of the queries I have in my project are with custom query builders, a feature carried over when I was still using Knex. I have since migrated all queries from to drizzle-orm, while keeping the custom query builders. This new requirement is a complete breaking change for me, one introduced in what's supposed to be a minor update.

Now I understand that I am probably in the minority in terms of using custom query builders, but I shouldn't have to deal with breaking changes for a minor update. If this library is to be used in a production environment, new features have to complement the existing codebase. Right now, I am stuck with v0.28.x until we find the time to change every query, which is unacceptable in my opinion.

For this specific feature, please create an option to disable it and revert to v0.28 behavior. In the long term, I implore the team to think more deeply about how changes will affect current users. I will have no choice but to switch to something else if this continues.

[Angelelz]

Hey @anthonyma94. Thank you for putting this write up together with the bad experience you had updating your drizzle to the latest version.
I myself had to do some changes in a medium size codebase after the update. I completely understand your frustration.
I'm not part of the drizzle team but I've become part of the community and I've been helping with PRs and other stuff.
I don't want to downplay the issue you are facing, but I would like to share some of my thought.
The new .$dynamic() implementation was a change only at the type level, the runtime was maintained exactly the same. So if you were to compile ignoring the errors, your app will run exactly the same way as before. Now, this is definitely not the correct answer to your inquiry, the truth is, you updated and now see a lot of type errors.
In any case, I would like to point out that the changes required in your codebase will be minimal. I went through the issues in my codebase in 15 minutes. I actually wrote a quick sed command to do it automatically for me.

sed -i 's/\.from(\([^)]*\))/\.from(\1).$dynamic()/g' your_file.ts

You can do this by file or by folder, making sure you're reviewing everything.

[anthonyma94]

Thanks for the response. Looking back, I may have titled the discussion wrong, and that's on me. $dynamic(), while a breaking change for us, is indeed an easy enough fix. The bigger concern in my opinion is that I no longer have faith that updating Drizzle will not break my project in some way.

The last few updates have been rough, requiring more patches, or with this update, breaking changes on our end. 0.28.x broke the type system until 0.28.5. Drizzle kit 0.20.0 migrations deleted a whole bunch of tables that shouldn't have been deleted. These are major bugs, that should have been caught fairly early on. If this "fail fast and iterate" model continues, I, and I'm sure many others, will have no choice but to migrate elsewhere. That would suck because I truly believe that Drizzle is a superior product and would hate to see it fail.

[Angelelz]

I think it's great that you brought these issues up in this scenario. Drizzle definitely does not have a "fail fast and iterate" model as Drizzle is not a startup trying to ship features as quickly as possible.
There were honest mistakes on some of the releases after 0.28.3 that were not found during the tests. There was an initial attempt to fix these issues that was pushed withing 24 hrs. of the release, but that wasn't enough, so another release was put out within the next day. The team worked really hard and since then, they have changed the release process to go through a beta/validation release at least for 24 hrs. before the actual release.
There is also a new set of tests to make sure all the imports are working properly as part of the test suite.
Drizzle-kit also requires some work, there are so many edge cases and the library is scheduled to be open sourced before the end of the year.

[anthonyma94]

Thanks for the information. At the end of the day I still see huge potential in Drizzle, and it's good to see new testing methods in place. I will close the discussion, thank you for the insight.

[AndriiSherman]

Hey @anthonyma94!

Thanks a lot for your feedback and detailed thoughts about Drizzle. We totally agree with you, and let me explain our plan a bit (which we will also duplicate in the docs, Discord, etc.). It seems to be very important information for users, and we don't have any words about it anywhere.

The downside for you as a user of production apps
Right now, Drizzle is before the 1.0.0 release, which means we are still trying to determine the best shape for the API to reach version 1.0. It also means that we are using minor updates and breaking changes, and patch updates are considered bug fixes that won't break anything. Most users are fine with that and are aware that before version 1.0, we may have changes like .$dynamic and so on.

The upside for you
We are left with a few things to change before reaching 1.0:

1. Add With Recursive (the pull request is already in the review stage).
2. Modify the table schema declaration a bit (not a breaking change), such as making table names optional and making the relations API easier.
3. Add the missing part to Drizzle Kit, like some index fields, checks, views, and proper schema support for Postgres.

With all of that, we see Drizzle ORM and Drizzle Kit as 1.0 and plan to add new features on top of it. We will also implement proper semantic versioning afterward, with breaking changes only in major releases.
As mentioned earlier, the current timeline is around December 2023/January 2024.

[anthonyma94]

Hi, thanks for the information. It's good to about the 1.0 changes, and I look forward to seeing it in production.