It doesn't appear to be explicitly documented, but looks like it can wrap
CALLs to stored procedures:
https://github.com/sqlc-dev/sqlc/blob/v1.27.0/internal/endtoend/testdata/ddl_create_procedure/postgresql/pgx/v5/query.sql
->
https://github.com/sqlc-dev/sqlc/blob/v1.27.0/internal/endtoend/testda
On 10/01/25, 'Brian Candler' via golang-nuts (golang-nuts@googlegroups.com)
wrote:
> On Thursday, 9 January 2025 at 19:49:23 UTC Roland Müller wrote:
>
> > Reason for that is that doing all DB access methods in the application
> > language (Go or Java) tends to a codebase where you have SQL code
On Thursday, 9 January 2025 at 19:49:23 UTC Roland Müller wrote:
Reason for that is that doing all DB access methods in the application
language (Go or Java) tends to a codebase where you have SQL code snippets
scattered over in your code. When the application now grows it will be more
and more
Hello,
I am actually scared by the fact to implement a bigger DB application on
plain code level and tend rather to use a ORM.
Reason for that is that doing all DB access methods in the application
language (Go or Java) tends to a codebase where you have SQL code snippets
scattered over in your
My statement will be unpopular fact.
My workplace using gorm for application with avg 3k qps. Even at some point
its exponentially increase to around 50k (campaign event). Its a big
project. Never had issue caused by gorm specifically.
On Thu, Jan 9, 2025, 9:41 PM Mike Schinkel wrote:
> On Jan
> On Jan 8, 2025, at 11:56 PM, Henry wrote:
>
> I am not aware of any SQL wrapper in Go, but then I didn't look hard enough.
> At work, we implemented our own SQL wrapper for a few databases we commonly
> work with. In .Net, you have LINQ, but LINQ is a query-only language. But the
> idea is t
Hi,
I am not aware of any SQL wrapper in Go, but then I didn't look hard
enough. At work, we implemented our own SQL wrapper for a few databases we
commonly work with. In .Net, you have LINQ, but LINQ is a query-only
language. But the idea is the same, which is to provide a common interface
wh
> On Jan 8, 2025, at 1:38 AM, Henry wrote:
>
> The reason people use ORMs is because they don't want to write SQL. ... A
> thin wrapper over SQL language that is portable across databases is a better
> solution.
That is insightful.
Do you know of such an existing solution that meets said re
The reason people use ORMs is because they don't want to write SQL. The
reason people don't want to write SQL is because SQL is not portable with
each database implements its own SQL variant/dialect. Switching databases
often involves rewriting the SQL instructions. But ORM is an overengineered
> WHERE email = CASE WHEN sqlc.arg(email) = '' then NULL else
sqlc.arg(email) END
What database is that? If it's Postgres then I believe that expression
collapses to
WHERE email = NULLIF(sqlc.arg(email), '')
But wouldn't it be better to pass null explicitly, rather than assume
"empty stri
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
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
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
It is not slow - but it will be if you don’t use it properly or set the
database up properly.
> On Dec 20, 2024, at 1:19 AM, Kerem Üllenoğlu wrote:
>
> Hey,
>
> I keep hearing ORMs - especially GORM - is slow. But I have never felted like
> it was slow and used in a couple of projects now. I
Hey,
I keep hearing ORMs - especially GORM - is slow. But I have never felted
like it was slow and used in a couple of projects now. Is there a good
article you recommend reading about ORMs in Go - especially GORM - being
slow?
Sorry, my reply is not actually an answer to the original questio
If you want to avoid boilerplate and keep the lightest weight possible,
you could have a look at the approach I took recently when I
added SQL support in my serialization format, greenpack.
See here: (only supports MariaDB/MySQL syntax at the moment)
https://github.com/glycerine/greenpack?tab=re
https://github.com/ent/ent seemed to perform well, and was quite flexible.
Will
On Thursday, December 19, 2024 at 7:27:46 AM UTC-8 Robert Engels wrote:
> I go back and forth on ORMs. I think a lot depends on the complexity of
> the project.
>
> Still, I wouldn’t expect the overhead of an ORM t
I go back and forth on ORMs. I think a lot depends on the complexity of the project. Still, I wouldn’t expect the overhead of an ORM to be more than 1-2% for IO/db bound systems - if it is I suspect it is not properly configured and it is generating inefficient queries or the database tables lack p
Hi Bhavesh,
I am also not a fan of ORMs, but I am a big fan of sqlc so I will 2nd Brian
Candler's recommendation.
Sqlc is one of the few Go packages/tools I consider a must-use for any of my
projects that need to interact with SQL databases.
-Mike
> On Dec 19, 2024, at 8:23 AM, 'Brian Candle
22 matches
Mail list logo
