samonzeweb

I definitely recommend Go. Not only for the language itself, but for the lesson about simplicity it provides. Sometimes developers using others languages uses and abuses of features to be productif, smart, ... causing more damage than benefict. It's not the way to do things in Go.

Go is multiplatform, and you can easily cross-compile for other OS or other CPU architecture. It produces a single binary then it's easy to deploy. It could be useful.

Go is really easy to learn, in a single day you will have a good understanding of the language itself. It's really something interesting to learn and practice a bit, without needing weeks of work. Even if it doesn't suit you, you had not loss many time.

It's not really implemented yet.

You can build nested queries, doing some extra work, but it's not elegant and will not work for any cases (especially with PostgreSQL) : https://gist.github.com/samonzeweb/b1ae3e2d1f3203ee1722ac4bd...

Some work to do to add proper nested queries into godb, but for a so simple example it doesn't seem to be extremely hard.

The projet started as a learning one. I made some independent and experimental component from time to time, and then glued them together, rewriting some parts, ...

Why this kind of project ? Because I used Active Record (Rails), Entity Framework, played with Django ORM, ... and regretted that nothing similar exist in Go world. Instead of complaining I choose to do something, not building a full ORM by myself, but at least build something allowing me to have a better comprehension of the constraints (except of the classic "no generic").

I didn't choose to build another Go library thinking I'll build something better than others. I learned, and I got a library ;)

I don't know CockroachDB, but if there is a Go sql driver (compatible with database/sql") and it uses standard SQL, you can write an adapter, see : https://github.com/samonzeweb/godb/tree/master/adapters

I took care of that, caching structs metadata to limit useless repetitive introspections, and others simple stuffs. But of course if will always be slower than manually crafted code.

With Go the cost is ridiculous compared to round trips with database server and query execution. More productivity for just a bunch of CPU cycles. Of course each use case and constraints are different, they're is no universal rules.

Entity Framework... that is slow ! I don't know for EF Core, but EF6 is really a slow thing.

As it was stated, godb isn't really an ORM. The README and documentation was updated.

Now godb is just "a Go query builder and struct mapper".

Thanks for all comments :)

> > It's composition tool, not a relational one. Sorry.

> Isn't the R in ORM for relational?

I spoke about the nested structs. You can have nested structs for something else than relational mapping.

As I replied to masklinn , I was not sure how to qualify godb, and I admit that ORM is not a perfect qualifier.

Nested structs are shown in the documentation : https://godoc.org/github.com/samonzeweb/godb#hdr-Structs_map...

It's composition tool, not a relational one. Sorry.

We agree. In fact I did not know how to qualify * exactly * godb.

I agree, it’s a simple tool. As mentioned in the README, it’s not a full-featured ORM, but it does more than building queries as it maps Go structs with databases content (on this point I disagree as it use objects).

The purpose is to be more productive than doing all this job manually.

Many things can be improved, it's sill a young project. This project is initially a learning one : doing stuff to improve my skill, on my spare time. I tried to build something clean, and used it on some real data. Perhaps it could be useful for somebody else. Nothing more ;)