From a660fe323974b26ee1f5f1bc7b70a7d0e9d9e827 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vin=C3=ADcius=20Garcia?= Date: Sun, 3 Jul 2022 22:58:38 -0300 Subject: [PATCH] Updated KSQL vs Other Tools (markdown) --- KSQL-vs-Other-Tools.md | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/KSQL-vs-Other-Tools.md b/KSQL-vs-Other-Tools.md index 3abda50..aa13382 100644 --- a/KSQL-vs-Other-Tools.md +++ b/KSQL-vs-Other-Tools.md @@ -1,27 +1,38 @@ ## Why KSQL and not SQLX, PGX, or GORM? +### Low-level tools: + If you have worked with the `database/sql` package, `sqlx` -or even `pgx` you might have felt as I did that it feels -awkward: +or even `pgx` you might have got the impression as I did that +it feels awkward. + +I did write a text explaining my concerns regarding these libraries, +so if you want a more in-depth view please [read it here](https://betterprogramming.pub/golang-sql-problems-with-existing-libraries-145a037261b8) + +But here follows a short description of the issues I find when working with these libraries: 1. Too many error checks even for simple queries -2. Easy ways of writing errors, like breaking the order of the `.Scan` arguments - forgetting to call `rows.Close()` or calling it before checking for errors, - missing some error check, forgetting to call `.Rollback()` or `.Commit()`. +2. Easy ways of writing errors, like breaking the order of the `.Scan` arguments, + forgetting to call `rows.Close()`, calling `defer rows.Close()` before checking for errors, + missing error checks, forgetting to call `.Rollback()` or `.Commit()` and so on. 3. There is a lot of code duplication in regards to attributes/column names, that need to be repeated on many different queries on the same struct. 4. No easy way to make common actions like inserting a record, making updates, partial updates, or deletes. +### High-level tools: + Because of that some people feel tempted to use ORMs and in Go the most famous one is GORM. However, ORMs are complicated tools that require the whole team to learn them, they are less stable -and readable than pure SQL and will often help developers to write bad and inefficient queries -or even bugs for lack of understanding of the tool. +and readable than pure SQL and will often allow or even encourage developers to write bad and +inefficient queries or even bugs for lack of understanding of the tool. > To illustrate this it might be enough to say that a quick search on > [GORM's godoc](https://pkg.go.dev/github.com/jinzhu/gorm#pkg-index) > shows it has in total 169 public functions. +### Tools relying on Code Generation: + Finally, we have Code Generation tools like `sqlc` and `sqlboiler`, and if that's your thing you might prefer to use them. However, there are also reasons not to: