5 ms·

When I started using go (coming from rails), ORM was really the thing I missed the most. And this made me realize I actually didn't know much about postgres. I

When I started using go (coming from rails), ORM was really the thing I missed the most. And this made me realize I actually didn't know much about postgres. I started using pg functions, views, triggers, etc and found it extremely convenient. Now, my sql strings in go are mostly `SELECT * FROM func_name(<$params>)` and I'm happy with that. I'm not saying ORMs are useless (active_record is an incredibly cool tool), but it's been surprisingly way easier to live without them that I'd thought.

tptacek 10y ago
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.
- oelmekki 10y ago
  > 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.
  - neospice 10y ago
    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.
    - oelmekki 10y ago
      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 https://github.com/mattes/migrate
- tedunangst 10y ago
  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.
  - dasil003 10y ago
    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.
    - ansible 10y ago
      If you are doing plain SQL in your golang app, I highly encourage you to check out sqlx: https://github.com/jmoiron/sqlx https://github.com/jmoiron/sqlx It has features like directly unpacking the results of a query into a structure. Very handy.
  - _ph_ 10y ago
    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.
- jryhurst 10y ago
  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 http://github.com/spacemonkeygo/dbx.
  - tptacek 10y ago
    I wrote something very similar, but this is exactly what I mean by writing 40% of an ORM.
  - stcredzero 10y ago
    I find this interesting. Are there examples around, or a blog post discussing this?
  - aleksi 10y ago
    Also see https://github.com/go-reform/reform https://github.com/go-reform/reform for a stable implementation of a similar idea.
- aleksi 10y ago
  That's why we created https://github.com/go-reform/reform https://github.com/go-reform/reform. It gives you type-safe (without interface{}) helpers for both common cases and reading custom query results.

tptacek 10y ago

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.

oelmekki 10y ago
> 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.
- neospice 10y ago
  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.
  - oelmekki 10y ago
    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 https://github.com/mattes/migrate
tedunangst 10y ago
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.
- dasil003 10y ago
  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.
  - ansible 10y ago
    If you are doing plain SQL in your golang app, I highly encourage you to check out sqlx: https://github.com/jmoiron/sqlx https://github.com/jmoiron/sqlx It has features like directly unpacking the results of a query into a structure. Very handy.
- _ph_ 10y ago
  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.
jryhurst 10y ago
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 http://github.com/spacemonkeygo/dbx.
- tptacek 10y ago
  I wrote something very similar, but this is exactly what I mean by writing 40% of an ORM.
- stcredzero 10y ago
  I find this interesting. Are there examples around, or a blog post discussing this?
- aleksi 10y ago
  Also see https://github.com/go-reform/reform https://github.com/go-reform/reform for a stable implementation of a similar idea.
aleksi 10y ago
That's why we created https://github.com/go-reform/reform https://github.com/go-reform/reform. It gives you type-safe (without interface{}) helpers for both common cases and reading custom query results.