This might be a tangent from the thread, but while I really liked SQLC, I
found that doing anything remotely dynamic became too cumbersome. I
started out with SQLC and had SQLX as a fallback.
As soon as you want to have optional filters you end up with a hideous
query you have to contend with.
F
Bhavesh,
Go is great for big projects.
You don't say specifically which part is slow, nor which
database you are using, so it is hard to give specific advice.
You should measure and profile to see what part of your
process is taking a long time. Go has great profiling tools.
That's one of the re
Ok, clear.
To say it easier, you annotate the first query to prefetch informations
from joint tables but keeping distinct their object representation.
Fair enough.
Still risky because it can explode, but definetly better than lots of
single queries.
PSK
On Sat, Dec 21, 2024 at 5:45 PM robert en
As I said, it is a common problem and readily solved if you know how to use the
ORM properly.
This is in Java, but the technique is the same
https://medium.com/geekculture/resolve-hibernate-n-1-problem-f0e049e689ab
> On Dec 21, 2024, at 10:40 AM, Luca Pascali wrote:
>
> The first one, yes.
>
The first one, yes.
The other 10k no, if they are called after in a loop in the user language
that runs over every row returned by the first query.
Like it is done in a lot of REST interfaces
That is the difference I was pointing out.
In fact I also said that in case of simple interfaces ORM doe
This is incorrect. Most ORM will efficiently execute the first query with a single SQL statement. It’s called the N+1 Select problem and it is solvable. On Dec 21, 2024, at 3:43 AM, Luca Pascali wrote:In my experience, ORM has a structural flaw, and it cannot be otherwise (as well as a lot of au
Opened https://github.com/golang/go/issues/70949
On Friday, December 20, 2024 at 10:57:50 PM UTC+1 Michael Pratt wrote:
> Could you file an issue about this with reproduction steps? My attempt to
> reproduce this works fine.
>
> go.mod
>
> ```
> module example.com
>
> go 1.24rc1
>
> tool (
>
In my experience, ORM has a structural flaw, and it cannot be otherwise (as
well as a lot of automatic tools)
Using ORM you are driven to write queries like (pseudo go code)
objects := Table.filter(some rules)
for o := range objects {
if o.field == 5 {
sub := Table2.filter(some other r
