how are they doing migrations?
Our journey in dropping the ORM in Go
91–100 of 157 posts
Re: Our journey in dropping the ORM in Go
#92Earlier quoted context omitted.
And when you eventually ascend to true mastery, you'll be able to enter a zen-like trance, in which you'll be able to tell when to use one or not, or indeed whether to use both (e.g. ORM for simple CRUD stuff, hand-written queries for everything else).
The problem is that most apps start out as simple CRUD apps. Also each dependency is a liability. People really underestimate how pulling in dependencies can lower your software quality. Most people have security bugs in mind, but there are also performance issues, memory leaks and logging-issues, needles abstractions and incompatibilities.
It's not a problem that they start as CRUD apps. That's exactly the place where ORMs or query generators should be used: CRUD code is always the same and as such should be 100% automated.
So then when something different than CRUD happens? You use the ORM, a query generator, or completely custom SQL, depending on which is the most appropriate to the situation.
Performance doesn't need to be an issue if the query is extremely rare; if it's core to your app, by all means, write completely optimized SQL. But if it's an extremely rare query or only shows up for your admin page? ORM code should be fine.
That's the point of the parent comment: When you get good enough you learn where to use each.
Re: Our journey in dropping the ORM in Go
#93So frustrating. You got like 80% of the way there, and then went "nope, too much work" and diverted to add more complexity. The answer is to write the SQL yourself, and the scan methods yourself. Code generation is better than ORM, but still a wrapper, still adds complexity, and still brings problems. Yes it's a pain in the arse to write all that boilerplate in one go (pun intended). But if you'd started without an O…
What is the idea behind using views? I have never used them
Not OP but two main things:
1. Access control - you can create new SQL accounts and only give them access to select from specified views
2. Encapsulation and implementation hiding - the underlying table structure can change as long as the views exposed doesn't change.
At least that's all I know. I'm sure people will add or correct when they read this.
Re: Our journey in dropping the ORM in Go
#94I did the exact opposite move - moving away from sqlc to gorm. Sqlc is great and fast and it was a joy to use, but I needed the ability to track changes to database models. So either I would build my own abstraction on top of sqlc or work with database triggers. Gorm provided an easy way to hook into all of that as well as making several update queries easier. I still think that sqlc should be the first choice when you don’t need more complex features, but gorm does provide a lot of goodies.
Re: Our journey in dropping the ORM in Go
#95Heh. Recently I had to stand up a quick elixir project and decided to write all queries by hand and not use Ecto. It was extremely enjoyable writing every query from the start. Just thinking carefully about what columns I needed, and crafting the best joins and where clauses made efficiency baked in from the beginning. If one is not careful and just be lazy with an ORM you get back all columns all the time - and this…
The problem is that writing SQL by hand tends to led to more errors. Experienced devs might be able to minimize those errors (and potential vulnerabilities, remember all those injection bugs?) but especially for junior devs I would recommend using an ORM to avoid shooting themselves in the foot. The question is Performance Security, which is most likely gonna be security for most people on the data/ application layer.
Re: Our journey in dropping the ORM in Go
#96So frustrating. You got like 80% of the way there, and then went "nope, too much work" and diverted to add more complexity. The answer is to write the SQL yourself, and the scan methods yourself. Code generation is better than ORM, but still a wrapper, still adds complexity, and still brings problems. Yes it's a pain in the arse to write all that boilerplate in one go (pun intended). But if you'd started without an O…
What is the idea behind using views? I have never used them
I used views several months ago when I implemented a tracking database for AWS SSM parameters: I wanted to retain a history of all changes to the parameters over time, and the schema was complex enough that queries for simple things like “what’s the current value?” weren’t simple at all.
So, I wrapped common queries in views.
(None of this should be taken as advice for how to approach such a problem.)
Re: Our journey in dropping the ORM in Go
#97This article would have been better without the unnecessary war analogy and history lesson.
Indeed the analogy has not aged well. It's in bad taste, and somewhat offensive, to hear the term "Vietnam of programming".
Yeah, as a Vietnamese, this title definitely feels offensive to me. Maybe this article is written with American audience in mind. In Vietnam we call the war American war btw. Depends on where you are from, the title could have used the term "USA of programming" :)
Re: Our journey in dropping the ORM in Go
#98As a junior dev I had no idea what an ORM was. As a mid-level dev I discovered them and wanted to use them everywhere. As a senior dev I've gone back to manually writing queries. Such is life.
I've gone past this and have a very clean and efficient query builder in my ORM. I maintain one for work and another is my open source PHP framework (15 years old now).
Mine supports simple joins and relationships but anything beyond that requires writing custom queries.
Re: Our journey in dropping the ORM in Go
#99Meenwhile I am "traped at a fortune 500 enterprise" with a half baked project that I think would address all this, yet to affraid to drop that job due to "stability" (which COVID came to meke laughable) and also too afraid to make it publicly available for I think its not yet ready even to start reveiving feedback (even tho I have been able to start usong it gor simple cases) and draming of the day I will be able to spend all my working hours on it...
Re: Our journey in dropping the ORM in Go
#100Shameless plug: I'm working with a small team on a data framework that replaces the ORM with an abstraction the eliminates the impedance mismatch. You can take a look at https://github.com/zeidon/zeidon-joe . I'd be happy to answer questions.