Task: Replace GORM

[RageCage64]

The rewrite of this project uses GORM for database interactions. Unfortunately, after using it for a bit on subsequent PRs, most of us really don't like it. Since it is still early enough to rip out, we think it would be a good idea to change course now rather than try to deal with GORM pain later.

Affected Functionality

The database package will have any GORM related functionality removed (with #60 most of the GORM actions are contained to the database package, but if there are any others they will have to be changed as well). The only model in the model package will also need to be changed to not embed gorm.Model.

[TheTedder]

Good thing we did that restructuring! I knew it would make things easier in case we needed to swap any individual part out. Here's a neat repo I found that lists a bunch of ORMs and ORM-like things. Maybe something on this list would be good enough: https://github.com/d-tsuji/awesome-go-orms

[RageCage64]

I didn't know there were so many ORM options for Go! 😮

Maybe it would be pertinent to think about what exactly we are looking for from a new data-access solution? Might help guide our decision. The way I personally see it we have two main problems

• We don't want to write raw SQL (even though we definitely have talented DB people in here it's probably best if we keep the raw SQL out of at least our data access code)
• We need an easy solution to keep our schema safely up to date
  Is there anything I'm missing there?

[FrozenSake]

I agree with the questions. I think it's important that we clarify why we want an ORM and what we want it to do for us. It feels a bit like we ended up with GORM because everyone went "we need an ORM," rather than because we liked any particular features of it. I think what we want is:

• Efficient queries
• Safe queries (protected against leaks, protected against injection)
• Schema definition
• Schema migration

Did I miss any? (Also I rephrased "not write raw SQL" as a combo of efficient and safe queries, because I think the goal of not-raw covers up the actual goals that drive that decision)

My question would be specifically around schema migration, how much load are we expecting the ORM to handle for us? I have a feeling this is the most handwaved part of choosing an ORM

[zysim]

For schema definition, do we want to consider Protobuf again? It'd help with accommodating gRPC too, if that's even what we want eventually.

[TheTedder]

I'm gonna take some of the advice that was given to me earlier and say that at this stage of the project, our emphasis should be on getting things up and running. With that in mind I think the ORM we want should be easy to use first and foremost and ideally easy to add new models to without having to hand-tweak every single field to make sure the db is storing them correctly. To this end, I think xorm looks decent. It seems to do a much better job of just working out of the box. Specifically, it has the following features that were missing or just wrong in gorm:

• string fields are varchar(255) by default instead of text
• []byte fields correctly map to bytea when using postgres instead of just throwing an error

[TheTedder]

here's what the repo might look like if we used xorm instead https://github.com/TheTedder/leaderboard-backend/tree/xorm

[robotmayo]

I am also not the biggest fan of GORM. I wonder if a lot of the issues have to do with how Go works as a language. The only thing id think we would miss is cascading updates tbh. For schema migration we should do that outside the ORM anyway, auto updating schemas is a nightmare.

[FrozenSake]

I do think go is generally a pretty good language for not using an ORM (which I think correlates to how many ORMs are... not great?), but there seems to be enough desire for one, and so long as we continue to keep implementations properly distinct, we'll always be able to "easily" switch out. Easily in quotes, because I think it's not actually easy, so much as minimum difficulty.

[zysim]

Honestly, I don't know too well whether we really need an ORM for Go or not; personally, I just thought we should. I'm really fine either way. If most of us would rather work with one, then I'm down; Xorm seems good as well. On the other hand, @FrozenSake you actually have experience with Go development, so I'm also down with not using an ORM too.

[FrozenSake]

I think it's largely irrelevant if we do or don't in terms of go performance and usability, and I'd say the ORM pattern is one that people are comfortable with, and we already have it, so ... just go with it? Ugh, I feel like a senior saying "It depends" and "both ways work". hahaha

[zysim]

👴

Alright then. Unless we get any pushback, I'd say let's go with Xorm