No, just write a repository to expose domain operations and implements them using SQL directly. Trying to fake OO object graphs against a RDBMS with a super-complex and leaky ORM is just painful.
Groovy’s ORM? I recall it being Hibernate under the hood and I had to fight with it to avoid common problems like hidden IO and N+1 query blowups (iterating over a set of results and then touching the wrong property means you are making another network call for each), learning its particular DSL for schema definition and associations, and not having a way to represent any but the simplest SQL constructs. The usual ORM stuff.
To the extent that you can write a syntax-checked SQL statement and it deserializes the results into some collection of row objects, it’s fine. But that’s not the “ORM” part.
No, just write a repository to expose domain operations and implements them using SQL directly. Trying to fake OO object graphs against a RDBMS with a super-complex and leaky ORM is just painful.
Would you classify GORM that way?
Groovy’s ORM? I recall it being Hibernate under the hood and I had to fight with it to avoid common problems like hidden IO and N+1 query blowups (iterating over a set of results and then touching the wrong property means you are making another network call for each), learning its particular DSL for schema definition and associations, and not having a way to represent any but the simplest SQL constructs. The usual ORM stuff.
To the extent that you can write a syntax-checked SQL statement and it deserializes the results into some collection of row objects, it’s fine. But that’s not the “ORM” part.
GORM is Go ORM
I have not used that GORM, but ORMs have those problems generally.
i prefer going GORMLESS