Hey @thunderbong One of Ent's maintainers here. Thanks a lot for sharing our project. To all others interested, Ariel (a8m) and I are here following this thread, so feel free to ask us anything and everything!
Thank you, you're doing an amazing job!
Ent: An Entity Framework for Go
51–60 of 68 posts
Re: Ent: An Entity Framework for Go
#52Earlier quoted context omitted.
Totally agree with you. Especially about point 1. Codegen is one of the bluntest tools there is and should be almost always avoided.
Why is that? I’ve done a few toy attempts to build out ORM-like model classes in Typescript that wrap an input schema type using typelevel features, and my profiles of the Typescript compiler show a lot of slowdowns coming from combinatoric explosions in the typechecker. In this language specifically, the type system has quite advanced expressiveness but using those features in practice runs into limitations of the c…
I said almost never not never, 64 variants is quite esoteric I'd say. The reason why I dislike codegen so much is that you fix one problem but introduce multiple new problems.
How do you handle the generated code? Do you check it into source control? If so, how do you ensure people do not touch it. Manually modified code generated code is one of the worst places to be in for maintenance. You mentioned you wanted language server support this means the generated code must not be ephemeral and continually visible to the rest of the project. When will this generated code need to be regenerated? On a schema change? How do you ensure the generated code always matches the schema?
Like I said all of these question can be answered, but it's quite a burden. In fact if I were you I would have looked into fixing the typescript compiler since the problems your ran into probably weren't fundamental. -
Re: Ent: An Entity Framework for Go
#53I hear Entity framework and code as schema I get nervous
The .Net entity framework has caused a lot of problems for clients in the past. I am not as familiar with the new one in .net core which is now just .net again I think.
A huge mess managing deltas for the schema.
Often used by people who do not know SQL nor relational databases that leads to enormously slow and resource intensive queries, (that can be done really easy and fast in raw Sql, and once you figure out how to EF is doing things) schemas that are suboptimal
Once you start fighting EF to make it behave better you lose a lot of the benefit of the abstraction in the first place…
Re: Ent: An Entity Framework for Go
#54I 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 lik…
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 active…
> I keep thinking that the query portion should be entirely split from the ORM portion
This is how SQLAlchemy does it. Lower level query tier you can use directly, and a higher level ORM tier that uses the query tier.
Re: Ent: An Entity Framework for Go
#55Hey @thunderbong One of Ent's maintainers here. Thanks a lot for sharing our project. To all others interested, Ariel (a8m) and I are here following this thread, so feel free to ask us anything and everything!
Thank you, you're doing an amazing job!
Thanks so much for the kind words.
Join us on our discord server (https://discord.gg/qZmPgTE6RX) to share what you're working on!
Re: Ent: An Entity Framework for Go
#56I thought this looked familiar.. Discussed 2 years ago: https://news.ycombinator.com/item?id=26008521 . (39 points, 9 comments)
I first heard about Ent on HN about 2 years ago. At the time I was evaluating every ORM in Go to find something that would fit the bill and Ent happened to be exactly what we needed. We've now been using it for 2 years and it's been one of the best bets we made on a technology choice. Things that have worked really well: * Auto DB migrations using Ent+Atlas. Ent implements a lot of great low level defaults that I jus…
Thanks for the kind words, Ivan! You're awesome
Re: Ent: An Entity Framework for Go
#57Earlier quoted context omitted.
Totally agree with you. Especially about point 1. Codegen is one of the bluntest tools there is and should be almost always avoided.
Why is that? I’ve done a few toy attempts to build out ORM-like model classes in Typescript that wrap an input schema type using typelevel features, and my profiles of the Typescript compiler show a lot of slowdowns coming from combinatoric explosions in the typechecker. In this language specifically, the type system has quite advanced expressiveness but using those features in practice runs into limitations of the c…
I guess you are aware of Prisma. What is your opinion of it in this context?
Re: Ent: An Entity Framework for Go
#58Earlier quoted context omitted.
I want to derive a Model type with methods from a Row type so I can write something like `const openDiscussions = blockModel.getContent({ where: c => c.getType() !== “page” }).andRecurse().getDiscussions({ where: d => !d.getResolvedAt() })` given an input row type like `type BlockRow = { id: BlockId, type: “page” | “text”, content?: BlockId[], discussions?: DiscussionId[] }; type DiscussionRow = { id: DiscussionId, r…
You cannot use the lambdas operators combo without a preprocessor (like ttypescript) mainly because closure captures cannot be accessed from the function AST. You will also need to use a tuntime dsl to describe the schema, and then derive both the model classes and the model types from it (just because runtime parts cannot be derived from types) Other than that, the rest is very possible.
> You will also need to use a tuntime dsl to describe the schema
This is kind of the whole ballgame right? How would you do any of this with types if the schema isn't defined until runtime?
Re: Ent: An Entity Framework for Go
#59I can see how EF was useful in a stateful server setup (tracking changes, etc) but I just don't get why it's very useful for stateless API servers. Write some SQL and map it using dapper
Re: Ent: An Entity Framework for Go
#60Earlier quoted context omitted.
You cannot use the lambdas operators combo without a preprocessor (like ttypescript) mainly because closure captures cannot be accessed from the function AST. You will also need to use a tuntime dsl to describe the schema, and then derive both the model classes and the model types from it (just because runtime parts cannot be derived from types) Other than that, the rest is very possible.
> You will also need to use a tuntime dsl to describe the schema This is kind of the whole ballgame right? How would you do any of this with types if the schema isn't defined until runtime?
I meant that since types are erased at compile-time in typescript, its much easier to make a schema description DSL that would then serve as the base to derive both the ORM DSL (runtime objects) and the types (compile time checks). If you go the types-first route, you will be forced to use proxies which can be more painful and constraining.
The popular choice here is to use classes plus decorators, but its not the only choice
https://typegraphql.com/docs/introduction.html#what
The convenient bit here is that classes already have both a type and a runtime representation, and decorators are also available to attach any extra metadata necessary to that runtime representation