Hacker News Reader

Comment by jollyllama | Hacker News Reader

Lack of db switchability and mockability are too much for me. Maybe I'm too old fashioned. But the author does a good job of highlighting these drawbacks.

View on HN

How often do you find yourself migrating DBs in the course of a project's lifetime?

Point taken, but IMO it is beneficial to split tests correctly into unit tests vs integration tests, so the ability to be able to mock the call or switch to a test db is highly desirable. Of all of the projects I've worked on over the last five years, there was some external impetus to change db's at least once.

In my past experience, any decently long lived bit of software (i.e. 5-10 years) goes through migrations to at least 2 different database engines (Usually as part of various other migrations like on-prem->cloud, or due to some licensing/$ reason) over its lifespan. And when you do it does tend to be quite a bit of work.

Same goes for java app containers.

I guess the question for me is:

Does implementing a different pattern that abstracts away the database engine substantially lower the amount of work it takes to migrate the db in the codebase, and is it worth 5-10 years of dealing with another layer of abstraction that is unused most of the time.

My hypothesis is that even with a more configurable pattern for the DB there is still a lot of code that needs to be changed.

sql.DB is already switchable/mockable underneath. Please stop mocking layers above it just to map to other SQL stores.

Reply on news.ycombinator.com