I’m a started golang early this year and I’ve used it to create APIs using gorilla mux and gorm. And also created recommendation engine using gorse. I will sincerely appreciate if I can network with someone that can get me any job opening or gig
I beg to differ. First off, raw SQL queries in your code are a great way to: 1) make your code readability suffer 2) introduce unchecked code that is basically stored in a string, so there's no guarantee it works 3) restrict your project to a specific DBMS 4) introduce potential vulnerabilities and so on. Also, SQL is highly declarative and SQL interpreters mostly don't care about how the query is structured. If you want to really "optimise" an SQL query to make it faster by modifying it, that's done in very non-obvious ways and is closer to randomly restructuring the query than to anything else, so it's safe to say that the structure of the SQL queries does not really affect their performance, and generating the queries with an ORM does not take significant time either.
I think Go ENT is the way to go if you’re using ORM. It’s entity framework for Go open sourced by META, which provides simple API for modeling any database schema as a Go object. Also, it’s easily traverse any graph structure since it’s graph-based framework. And most importantly it’s 100% statically typed and generates fully secure code for accessing and manipulating DBs. Go ENT is even more performant compared to GORM.
That looks complicated as hell. What are the advantages of ENT over not using SQL (which is what ent is built on) but going with MongoDB straight away?
i would love using gorm when developing a really big project with complex or complicated database query because it more easier and readable using orm than the raw query
There are a lot of articles that talk about the importance of mainting certain context in programming and the penalty (mentally speaking) that comes with switching from one context to another, for instance, from Go to SQL, from SQL to docker, etc. I think ORMs serve very well that purpose. I also agree in that they come with a small performance cost, but being realistic, probably the great majority of apps doesn't app require us to squeeze it to the last milisecond of latency. I think readibility should come first when it comes to small or medium projects, for large projects probably architecture problems are more of a worry compared to whether the app uses or not an ORM. By the way, I love your videos, I always learn new things! keep up the good work and thank you for creating content for us.
I have used gorm on many projects with gin and fiber. It never caused any problem to me rather made development quicker. the problems you mentioned is true to every other orm out there in other technologies too.
Funny thing about ORMs. Always somebody complaining about them. Just about every modern language has at least one. I guess there must be use cases for them then? No one writes these things for nothing. Of course there are times when you need tweaked raw SQL for certain applications but for most things you really don't...
as someone who used both i prefer to use orm in certain situation its not like the orm forces you to use it. type safety and simple short queries validation middleware is where i mainly use it if the query is expected to be long i just use function queries within the database it self. orm is only bad when your still typing the table names manually or still escaping string manually
Our company created soft realtime infrastructure paymeny with golang and gorm and event driven architecture . That is one of fastest infra in our country between payment companies. We use gorm for model first approach and great migration system for complex systems . Just our big issue was gorm new version heavily changed and produced some issue in our system
Misleading title. The reasons mentioned here are reasons why go developers would hate AN orm mapper, not Gorm specifically. None of these culprits are exclusive to Gorm. I'm a fan of rawsql myself, but then you gotta consider the security (sql injection preventation), db migration and all kinds of other fun stuff that an ORM handles for you out of the box. So as with most things, it's a tradeoff.
for initiate database gorm is good, but for migration maybe not yet.... how if we would change structure of table ex: rename column, delete column that we design before. What happen with our data ?
I have tried entgo. The team I work with really liked the entity representation, but very quickly we realised it's not helping. As time went on, it became much easier to just write raw SQL, because we needed a lot of complex joins, mostly joins that ent doesn't support...
because they generate go files, with no dependency on the sql compiler. sqlc takes your schema, and a file containing queries and converts it into model structs, and a query struct. The end result is vanilla go with no external dependencies.
Thanks for changing the voice. You are really knowledgeable no doubt but your accent is hard to understand. Thanks for listening to feedback. Now I will watch your content for sure
Honestly most go libraries have terrible documentation and gorm is a step above . I usually end up having to step into the source code and see what it does .
So I use gorm without the relations . I just use it for basic crud and batch creates etc . the rest of the relations I'll just hand write the sql query that does the join . I dont like sqlx because the structure binding is way too strict . and I sometimes want to scan to map[string]interface{} . so I have to use gorm otherwise I have to use sql.db and write 10 lines for a get me something query .
There is a limited amount of tens of hours I'm willing to put into debugging stupid errors like `ERROR: column "manufacturername" does not exist (SQLSTATE 42703)`. That amount is 3. Screw GORM and screw ORMs. Never again. Literally lost 5 days of work to it.
This video is much too shallow. ORM's are bad because they are not good at dealing with overly complex queries compared to a programmer? JOINS of any kind and overly complex queries should be avoided at all cost anyway. Anyone needing those should probably spend more time on their database architecture than on writing magic 15-line queries. ORMs really level up the dev experience and provide a uniform abstraction layer. Working on a bigger project I with multiple people I would always recommend using one. I think GORM does a good job as a minimal library although the documentation is a bit lacking.
JOINS of any kind and overly complex queries should be avoided at all cost anyway? How laughable. What about CTE's? Window functions? Material Views? Recursive queries? Table partitioning? Custom Aggregates? Your database doesn't need an abstraction layer. It needs someone who doesn't think it's a weird file system or a GUI-less spreadsheet. If all your building is toy CRUD apps then just use an unstructured key value store and leave relational databases to those that understand them.
Libraries like GORM/ENT makes you weak in programming/design and it also reduces your problem solving abilities. That means less chance you will get hired by FAANG type companies as these companies hire only engineers who don't rely on third party libraries like GORM/MUX etc.
@@someoneanonymous6707 In doing that, developer just learns framework/library and not programming. Ironically, majority of product companies like Google/Apple discard the resume if you say "I am using xyz framework"
No it doesn't. Using a library means you save time and can focus on solving the problem at hand and don't have to rely on reinventing the wheel again. Also, using GORM it makes it super easy to change to use MSSQL, Postgres, SQLite or MySQL databases without having to bother with the SQL differences. This is very handy because you most likely don't care about the nuances in SQL for the different databases.
@@makesnosense6304 Don't care about nuances in SQL? But interviewers ask inner/outer join questions and ask you to design database for full stack positions. Saving time, yes but startups and FAANG companies are less likely to hire developers who use frameworks/libraries. There will be some exceptions ofcourse.
Get your *FREE Golang Cheat Sheet* -
golangdojo.com/cheatsheet
I love gorm not as an orm, but as a quick and dirty db migration tool that allows making database creation and recreation hidden from a user
why hate it ? I've done a lot of projects using gorm and earned money from it XD
I’m a started golang early this year and I’ve used it to create APIs using gorilla mux and gorm. And also created recommendation engine using gorse. I will sincerely appreciate if I can network with someone that can get me any job opening or gig
I beg to differ. First off, raw SQL queries in your code are a great way to:
1) make your code readability suffer
2) introduce unchecked code that is basically stored in a string, so there's no guarantee it works
3) restrict your project to a specific DBMS
4) introduce potential vulnerabilities
and so on. Also, SQL is highly declarative and SQL interpreters mostly don't care about how the query is structured. If you want to really "optimise" an SQL query to make it faster by modifying it, that's done in very non-obvious ways and is closer to randomly restructuring the query than to anything else, so it's safe to say that the structure of the SQL queries does not really affect their performance, and generating the queries with an ORM does not take significant time either.
100% agree
Normally, it's solved architecturally. Isolate all DB access to repository classes.
It also ensures consistency across your codebase...
On every video you say to get your cheatsheet, then when I go to the link, it doesn't work.
I think Go ENT is the way to go if you’re using ORM. It’s entity framework for Go open sourced by META, which provides simple API for modeling any database schema as a Go object. Also, it’s easily traverse any graph structure since it’s graph-based framework. And most importantly it’s 100% statically typed and generates fully secure code for accessing and manipulating DBs. Go ENT is even more performant compared to GORM.
Thanks for the heads up on this, will check ENT out.
That looks complicated as hell. What are the advantages of ENT over not using SQL (which is what ent is built on) but going with MongoDB straight away?
Ent is unnecesaary complications and generates code without even asking. Varchars are a mess too.
i would love using gorm when developing a really big project with complex or complicated database query because it more easier and readable using orm than the raw query
There are a lot of articles that talk about the importance of mainting certain context in programming and the penalty (mentally speaking) that comes with switching from one context to another, for instance, from Go to SQL, from SQL to docker, etc. I think ORMs serve very well that purpose. I also agree in that they come with a small performance cost, but being realistic, probably the great majority of apps doesn't app require us to squeeze it to the last milisecond of latency.
I think readibility should come first when it comes to small or medium projects, for large projects probably architecture problems are more of a worry compared to whether the app uses or not an ORM.
By the way, I love your videos, I always learn new things! keep up the good work and thank you for creating content for us.
I have used gorm on many projects with gin and fiber. It never caused any problem to me rather made development quicker. the problems you mentioned is true to every other orm out there in other technologies too.
Funny thing about ORMs. Always somebody complaining about them. Just about every modern language has at least one. I guess there must be use cases for them then? No one writes these things for nothing. Of course there are times when you need tweaked raw SQL for certain applications but for most things you really don't...
A back-end developer that doesn't know SQL is a like a front-end developer that doesn't know CSS
as someone who used both i prefer to use orm in certain situation its not like the orm forces you to use it. type safety and simple short queries validation middleware
is where i mainly use it if the query is expected to be long i just use function queries within the database it self. orm is only bad when your still typing the table names manually or still escaping string manually
- do you hate GORM
+ yes
- are you using it
+ yes
Our company created soft realtime infrastructure paymeny with golang and gorm and event driven architecture . That is one of fastest infra in our country between payment companies.
We use gorm for model first approach and great migration system for complex systems . Just our big issue was gorm new version heavily changed and produced some issue in our system
Misleading title. The reasons mentioned here are reasons why go developers would hate AN orm mapper, not Gorm specifically. None of these culprits are exclusive to Gorm.
I'm a fan of rawsql myself, but then you gotta consider the security (sql injection preventation), db migration and all kinds of other fun stuff that an ORM handles for you out of the box. So as with most things, it's a tradeoff.
for initiate database gorm is good, but for migration maybe not yet.... how if we would change structure of table ex: rename column, delete column that we design before. What happen with our data ?
Does Tommy have a RUclips channel?
Any recommended Type safe Query builder other than go-jet , go-structured-query, sqlc _
ent by meta
what about entite library like entgo?
I have tried entgo. The team I work with really liked the entity representation, but very quickly we realised it's not helping. As time went on, it became much easier to just write raw SQL, because we needed a lot of complex joins, mostly joins that ent doesn't support...
How is an sql compiler not just another dependency along side Go?
because they generate go files, with no dependency on the sql compiler. sqlc takes your schema, and a file containing queries and converts it into model structs, and a query struct. The end result is vanilla go with no external dependencies.
Thanks for changing the voice. You are really knowledgeable no doubt but your accent is hard to understand. Thanks for listening to feedback. Now I will watch your content for sure
Sqlc is probably a much better alternetive to gorm.
100% I agree, we hate gorm
GORM can also run a raw SQL. What about Ent?
sql compiler video please
Also the documentation sucks
Honestly most go libraries have terrible documentation and gorm is a step above . I usually end up having to step into the source code and see what it does .
So I use gorm without the relations . I just use it for basic crud and batch creates etc . the rest of the relations I'll just hand write the sql query that does the join . I dont like sqlx because the structure binding is way too strict . and I sometimes want to scan to map[string]interface{} . so I have to use gorm otherwise I have to use sql.db and write 10 lines for a get me something query .
haizzz, I struggling in create generic repository in gorm
What did gorm do he is a good youtuber
node started with dislike of orm now people just use orm but still have a pure sql style or just pure orm
Thank you
why golang devs do we hate everything? Lol jaja xD
I hate ginkgo test library so much.
i hate it too XD
No I works and like gorm with associations I have no issue
Who's this tommy guy? is ha a youtuber too?
There is a limited amount of tens of hours I'm willing to put into debugging stupid errors like `ERROR: column "manufacturername" does not exist (SQLSTATE 42703)`. That amount is 3. Screw GORM and screw ORMs. Never again. Literally lost 5 days of work to it.
any one tried sqlc?
How dare you hate the furcorn goomba >:(
Too bad there is no equivalent for hibernate with HQL in go world.
This video is much too shallow. ORM's are bad because they are not good at dealing with overly complex queries compared to a programmer?
JOINS of any kind and overly complex queries should be avoided at all cost anyway. Anyone needing those should probably spend more time on their database architecture than on writing magic 15-line queries.
ORMs really level up the dev experience and provide a uniform abstraction layer. Working on a bigger project I with multiple people I would always recommend using one. I think GORM does a good job as a minimal library although the documentation is a bit lacking.
JOINS of any kind and overly complex queries should be avoided at all cost anyway? How laughable. What about CTE's? Window functions? Material Views? Recursive queries? Table partitioning? Custom Aggregates? Your database doesn't need an abstraction layer. It needs someone who doesn't think it's a weird file system or a GUI-less spreadsheet. If all your building is toy CRUD apps then just use an unstructured key value store and leave relational databases to those that understand them.
gorm is very slow
its getting people mad when migrating your system to a shit database that gorm does not support
Why Mika Fans Hates GolangDojo...
but I love gorm.
Libraries like GORM/ENT makes you weak in programming/design and it also reduces your problem solving abilities. That means less chance you will get hired by FAANG type companies as these companies hire only engineers who don't rely on third party libraries like GORM/MUX etc.
The entire idea of ORM is to code fast and with fewer mistakes which from a professional point of view is gold as it is saving time.
@@someoneanonymous6707
In doing that, developer just learns framework/library and not programming. Ironically, majority of product companies like Google/Apple discard the resume if you say "I am using xyz framework"
you think it's 2005 or something? I hope you are writing all your code in assembly too, you weak programmer ;)
No it doesn't. Using a library means you save time and can focus on solving the problem at hand and don't have to rely on reinventing the wheel again. Also, using GORM it makes it super easy to change to use MSSQL, Postgres, SQLite or MySQL databases without having to bother with the SQL differences. This is very handy because you most likely don't care about the nuances in SQL for the different databases.
@@makesnosense6304
Don't care about nuances in SQL? But interviewers ask inner/outer join questions and ask you to design database for full stack positions. Saving time, yes but startups and FAANG companies are less likely to hire developers who use frameworks/libraries. There will be some exceptions ofcourse.
I always learn something new here, thanks ninjas