Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ent: An Entity Framework for Go

github.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Ent: An Entity Framework for Go

#41

Post by kbumsik »

valenterry wrote: post #5

> 100% statically typed and explicit API using code generation. Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code. It's annoying to inspect and maintain and usually has quirks that I have to work around. How do Go developers feel about that?

I started to like Go's code generation approach.

Code generation make you very productive since IDE's auto-complete and code search works perfectly and snappy with the generated code.

The only complaint is that it tends to make noise during code reviews because they include autogenerated code too.

Re: Ent: An Entity Framework for Go

#42

Post by vbezhenar »

kbumsik wrote: post #41
valenterry wrote: post #5

> 100% statically typed and explicit API using code generation. Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code. It's annoying to inspect and maintain and usually has quirks that I have to work around. How do Go developers feel about that?

I started to like Go's code generation approach. Code generation make you very productive since IDE's auto-complete and code search works perfectly and snappy with the generated code. The only complaint is that it tends to make noise during code reviews because they include autogenerated code too.

Is it considered OK to commit autogenerated code? With Java I don't do that. It's generated during build phase in output folders but never commited to the VCS. Never had any issues with that.

Re: Ent: An Entity Framework for Go

#45

Post by guggle »

jitl wrote: post #11
Fire-Dragon-DoL wrote: post #4

Earlier quoted context omitted.

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…

In a typical ORM I agree about the query builder. Most ORMs encourage the typical use of a relational database where SQL fits the domain well. But Ent is modeling data as a graph, and the DB behind the scenes is more of an implementation detail. The production version of Ent used at Meta stores data in TAO ( https://engineering.fb.com/2013/06/25/core-data/tao-the-powe... my impression is that product engineers do not…

> the DB behind the scenes is more of an implementation detail

Ugh... what a bummer then.

Re: Ent: An Entity Framework for Go

#46

Post by [deleted] »

bottlepalm wrote: post #31

I'd kill for a port of the .Net Entity Framework to JavaScript - the current ORMs for JavaScript are really nothing compared to EF.. If you haven't used it, it is super powerful at selecting super complex structured data from a database super easy. :) It's query format is also the linq standard so you use the same extension methods to work with in-memory collections as you do with database tables.

[deleted]

Re: Ent: An Entity Framework for Go

#47

Post by a8m »

guggle wrote: post #45
jitl wrote: post #11

Earlier quoted context omitted.

In a typical ORM I agree about the query builder. Most ORMs encourage the typical use of a relational database where SQL fits the domain well. But Ent is modeling data as a graph, and the DB behind the scenes is more of an implementation detail. The production version of Ent used at Meta stores data in TAO ( https://engineering.fb.com/2013/06/25/core-data/tao-the-powe... my impression is that product engineers do not…

> the DB behind the scenes is more of an implementation detail Ugh... what a bummer then.

Just to emphasize, that OSS version of Ent models SQL tables in the traditional way (edges as foreign-keys and join-tables). i.e., the database structure is not obscure or something and can be easily read by developers and ported to other ORMs in case it's needed.

Re: Ent: An Entity Framework for Go

#48

Post by kbumsik »

vbezhenar wrote: post #42
kbumsik wrote: post #41

Earlier quoted context omitted.

I started to like Go's code generation approach. Code generation make you very productive since IDE's auto-complete and code search works perfectly and snappy with the generated code. The only complaint is that it tends to make noise during code reviews because they include autogenerated code too.

Is it considered OK to commit autogenerated code? With Java I don't do that. It's generated during build phase in output folders but never commited to the VCS. Never had any issues with that.

There is nothing wrong with committing generated code in Ent and Go. I don't know about Java but in Golang it does not create any platform-specific code in general, so committing code in the VCS would ensure reproducibility.

It is still OK to commit without generated code and things won't break as long as you pinned the package versions correctly. But some people don't like to put extra burden in the build phase. So it is totally organization's decision whether to commit generated code or not.

Re: Ent: An Entity Framework for Go

#49

Post by winrid »

Every time I try to create a new project in some sort of actor/graph manner I end up just creating some DB indexes and crons instead. Maybe I'm just not thinking big enough, but I hope I get to work on something that justifies this architecture someday because it looks like fun

Re: Ent: An Entity Framework for Go

#50

Post by spion »

jitl wrote: post #30
spion wrote: post #25

Earlier quoted context omitted.

> Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining. TypeScript can do this. It was done already halfway-well 6 years ago with way fewer features in TypeScript ( https://github.com/brianc/node-sql/blob/master/lib/types.d.t... ) - today we can do much better.

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.

Post reply on HN