[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)