This is the third part of the pgx v5 series. Let’s discuss the new features from the title.
CollectRows and RowToStructByName # CollectRows allow us to fetch an array of rows and set them into a slice of structs. Further, RowToStructByName is a long awaited feature which allows to store a row into a struct. sqlx module became very popular in Go community exactly for this reason, but pgx now supports something similar. RowToStructByName is a generic function of the func(row CollectableRow) (T, error) and it’s not the only one of this type, there are also RowTo, RowToStructByPos and RowToStructByNameLax. Under the hood, RowToStructByName is using reflection so it may be slightly slower than classic way of scanning the rows, but if you don’t mind this, it is very easy to use. All field names are going to be mapped to lowercased public struct field names and you may also use db struct tags if some field name differs from the struct field name. This explanation may sound difficult, but the following example will actually show that it is actually very easy to use.
In this second part of the pgx v5 series, we are going to discuss the QueryRewriter interface and NamedArgs. Let’s first check out the signature of the Exec method of the pgxpool.Pool struct.
Go has very rich standard library which also contains database/sql module with generic interface over SQL databases. Further, lib/pq PostgreSQL driver is fully compatible with database/sql and provides all basic database operations. However, since this is generic implementation over all supported databases, using it is a trade-off not supporting some PostgreSQL specific features. Fans of PostgreSQL (in further text pg) may want more and here comes pgx in help. pgx is a very rich pg driver supporting LISTEN / NOTIFY, COPY, type mapping between pg and Go, all specific pg types, wire protocol and much more.
Go is over ten years old language but generics (type parameters) are introduced just in the March this year. Hence, still lot of developers avoid using them or have certain problems once decided to give it a try. One of the common problems is how to check the concrete type of a generic parameter, specially of non constrained parameters. So, if you try to do the following, it won’t work:
Lot of the tutorials on the Web show different ways of writing Go HTTP middlewares, but most of them use functional approach meaning using functions that get dependencies as parameters and return HTTP handler function or handler. There is nothing wrong about this, but it can be quite messy to write a complex middlewares like database based authentication and authorization or simply middlewares which have lot of dependencies. In this article I am going to explain how to use more object oriented way of writing such middlewares. Let’s start with the basic object oriented middleware example:
Few days ago Go 1.18beta1 was released and with it the first official generics support. I was embarrassed with standard Go’s HTTP handler functions for quite a while. If you are not familiar with Go, you probably wonder why, but if you are familiar, I believe you know. For example, implementing a RESTful API using idiomatic Go requires lot of code repetition in order to JSON decode request bodies and JSON encode response bodies. This problem was possible to solve in some way but never in such elegant way like using generics.
According to lot of online polls, Visual Studio Code is the most popular IDE among Go developers. You can start Go development immediately after installing Go extension for VSCode, but some tuning may make your life easier. First of all, you may want to format the source code and reorganize imports automatically on each file save or code paste. In order to do so, put the following JSON snippet in your settings.json:
In the very early adoption of Go by the open source community, lot of developers already suggested the lack of generics. However, some other claimed that simplicity of Go shouldn’t be compromised by generics. Few days ago, the never ending discussions pro and contra generics are finally over. The proposal is accepted and we can expect generics in Go 1.18 somewhere in spring of 2022. You may wonder why does it take that long, but this is not just about the compiler but also some parts of the standard library may need to be rewritten in order to replace the old code which could benefit from generics.
If you have just started learning Go or already developing in Go for quite some time, you may noticed that most of the Go packages are imported directly from their respective VCS repositories, but there are some packages imported from URL’s like golang.org/x/text or go.uber.org/zap . If you try to visit such URL’s, you may see different results like being redirected to documentation or just some dummy page. This is completely different from packages hosted on GitHub, for example github.com/pkg/errors where you can see the real source code. This feature of Go is called vanity imports.
In these uncertain times and multiple months of remote work, at least we have some more time to dive into something new. I have been developing in Go since 2017, learned some TypeScript in the meantime, but few days ago I wanted to get into Rust once again. First time, approximately a year ago I gave up very quickly, realizing that Rust requires lot of time to learn and I didn’t have that much time at the moment.
