Hacker News Reader

Comment by tptacek | Hacker News Reader

Even writing Postgres functions, you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) over and over again.

People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it.

View on HN

I'll argue this point. It takes me 30 seconds to write a SQL query. It's not hard. On the flip side, I don't end up running queries that haul megabytes of data in just to peek at one column.

SQL is already much higher level than assembly. Piling on more abstraction just increases the likelihood that the code is doing extraneous work.

I agree SQL is not hard, but getting the data into objects is definitely repetitive work. ORMs are a double-edged sword where people who don't know SQL write bad ORM code because they can, but a good ORM gives various ORM level that allow one to do the right thing and still save a lot of repetitive boilerplate.

If you avoid an ORM, the typical medium sized CRUD app usually ends up with some poorly conceived bespoke abstractions that would be better used by some flavor of ORM. I'm with you that ORMs make it way too easy for junior devs to blow their leg off, but I still think they provide some very solid abstractions when used correctly.

If you are doing plain SQL in your golang app, I highly encourage you to check out sqlx:

https://github.com/jmoiron/sqlx

It has features like directly unpacking the results of a query into a structure. Very handy.

Fully agree. ORMs save you typing if you just need to wrap a table, but for complex multi-table queries I have seen really bad performance as a result. I rather prefer to capture my queries in a view, and then wrapping that is so trivial, that I don't need an ORM.

> People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it.

I have to assume those people did not first learn and use C, then went to assembly, but rather the opposite ;) So, the comparaison does not apply, here.

> you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD)

It's not the case, actually. My functions are way more expressive that the crud I did with orms. With PL/pgSQL, I group several queries in a same pg function, I always do more that a simple insert or update. I also fine tune my returned fields - which most of the time are composite from several tables / computations.

This is really outsourcing all data manipulation to the database, the comparison that applies is more with a presenter/serializer than with an orm model.

What are the typical trade-offs of outsourcing all the data manipulation & lookups to the DB. Are there cases when this is absolutely what you don't want to do?

I realize this is a very general and vague question but it's something I've been pondering about.

By far, it is dealing with migrations.

Initially, I would use `\ef <func_name>` in psql and just write and try my function, but this turned out to be not as pleasant as writing code in an editor in a dedicated file. The annoying thing with pg functions is that, if you want to replace them, you have to provide exactly the same in and out parameters. This means that if you want to change the parameters, you have to drop the function and create a new one.

This has been annoying at first, but now I'm more comfortable with it. I write my functions as migration files [1] and just migrate/rollback to do my tests. I guess I started to give more attention to the input and output parameters from the start in the mean time.

The cases where I won't use functions is when I want to do something extremely simple, like `SELECT email FROM users WHERE id = 1`. It's just not worth writing a function for that. It doesn't happen often that this is all I need to process my request either.

[1] I use https://github.com/mattes/migrate

We prevented the grossness of writing things over and over again by just using Golang's script generation and some other stuff. http://github.com/spacemonkeygo/dbx.

I wrote something very similar, but this is exactly what I mean by writing 40% of an ORM.

I find this interesting. Are there examples around, or a blog post discussing this?

Also see https://github.com/go-reform/reform for a stable implementation of a similar idea.

That's why we created https://github.com/go-reform/reform. It gives you type-safe (without interface{}) helpers for both common cases and reading custom query results.

Reply on news.ycombinator.com