[HN Gopher] Ent: An Entity Framework for Go
       ___________________________________________________________________
        
       Ent: An Entity Framework for Go
        
       Author : thunderbong
       Score  : 26 points
       Date   : 2022-10-30 21:16 UTC (1 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | metadat wrote:
       | I thought this looked familiar..
       | 
       | Discussed 2 years ago:
       | 
       | https://news.ycombinator.com/item?id=26008521.
       | 
       | (39 points, 9 comments)
        
       | jitl wrote:
       | I think Ent for Go has a ton of potential. Although I haven't
       | used this library, I have spent a lot of time studying the design
       | space of ORMs because I'm currently iterating on an internal
       | library that does ORM-like things at Notion. I really like the
       | Ent approach because it allows working with a graph-based data
       | model directly in the embedding language, instead of forcing
       | developers to learn a new query language like Datomic datalog or
       | SPARQL, while simultaneously avoiding lock-in to a specific data
       | store backend.
       | 
       | I would like to build something like Ent that is ergonomic and
       | usable on both the client and the server in Typescript, and
       | facilitates easily moving business logic between the two. The
       | context at Notion is that we have a very smart client using
       | something ORM-like and a somewhat dumb server using plain row
       | record values, so while we do share some code between the two,
       | it's difficult to port larger features from the client to the
       | server. It's kind of the reverse situation that most people have,
       | which is a smart server pushing GraphQL to a relatively dumb
       | client.
       | 
       | There are a lot of people looking into client-focused or end-to-
       | end database abstractions right now, so the space exciting. What
       | the upstarts should learn from Ent is:
       | 
       | 1. Codegen is powerful, and often easier to understand than a
       | mountain of typelevel magic.
       | 
       | 2. A good ORM solution should really build in permissions and
       | composing mutations at a deep level. The previous generation of
       | ORMs like ActiveRecord left this stuff to user space to
       | everyone's detriment.
       | 
       | 3. Embedded DSL as query language is a blessing and a curse. It's
       | better than forcing engineers to learn a weird alternative to SQL
       | strings, but more frustrating to experts. Use these tradeoffs
       | with caution!
        
         | Fire-Dragon-DoL wrote:
         | I keep thinking that the query portion should be entirely split
         | from the ORM portion. Query builder have specific usage, but
         | are not the norm. None of them can model an advanced postgres
         | query, but at the same time, they provide little (or nothing)
         | utilities to map the data coming from a complex query, back to
         | objects, which is funny, to me that would be the definition of
         | "object relational mapper".
         | 
         | I know why activerecord does this: it's way easier to do the
         | join in memory, so that one row is obtained per object and not
         | an enormous row representing many, but not providing any
         | utility for raw queries seems a big missing feature.
        
       ___________________________________________________________________
       (page generated 2022-10-30 23:00 UTC)