Roadmap

[amanbolat]

Hi, authors of go-jet,

Is there any roadmap for this project?

[go-jet]

Hi @amanbolat ,

At the moment development is mainly run per feature/bug request. Is there some missing feature you are interested in?

[amanbolat]

Hi @go-jet,

I want to know more about the future of the project. The project seems to be very promising, and such an approach of strictly typed SQL queries in golang is awesome, yet it would be nice to know who or how many people use it in production and is there any issue or any implications of using go-jet in big projects.

A few suggestions from my head:

1. Add more documentation, so the users know how does go-jet works and what is going inside the schema loader and code generator. It'll be beneficial if the project is abandoned for some reason in the future, and anybody could easily continue the work on it.
2. Add the feature to enable users to generate the code for internal schemas, such as information_schema in Postgres. It is very useful for those who creates the tooling around the database.
3. Maybe add more abstraction to QRM, so it doesn't use sql.Rows, but its own abstraction. As a result, enable users to use pgx.Rows without switching to pgx.stdlib wrapper.

Those are just my thoughts and suggestions. Any feedback is appreciated.

[go-jet]

Hi @amanbolat

1. Add more documentation, so the users know how does go-jet works and what is going inside the schema loader and code generator. It'll be beneficial if the project is abandoned for some reason in the future, and anybody could easily continue the work on it.

Agree, this part needs more documentation.

2.  Add the feature to enable users to generate the code for internal schemas, such as information_schema in Postgres. It is very useful for those who creates the tooling around the database.

This feature is already available in jet generator, although not officially supported(it needs to be covered with tests). information_schema can be accessed just like any other schema. For instance:

jet -dsn=postgresql://user:pass@localhost:5432/jetdb?sslmode=disable -schema=information_schema -path=./.gen

I believe this project is using jet generator to generates information_schema - https://github.com/lawrencejones/pgsink

3. Maybe add more abstraction to QRM, so it doesn't use sql.Rows, but its own abstraction. As a result, enable users to use pgx.Rows without switching to pgx.stdlib wrapper.

I haven't used pgx library that much and it's unclear to me what was the reason to replace the standard sql interface with a new one. Technically it is possible. On top of my head, drawbacks would be increased complexity and probably latency if there is some coping required. There might be some others as well.
The standard sql package is made to be a standard interface, and the driver is the place where the database-specific staff goes.
At the moment, I don't see a reason to add another layer of abstraction on an already standard one, for just one library. Although I could be wrong there might be some other libraries or use cases for such a feature.

[amanbolat]

Hi @go-jet,

Thank you for the reply.

Just tried the command above and it worked:

jet -dsn=postgresql://user:pass@localhost:5432/jetdb?sslmode=disable -schema=information_schema -path=./.gen

Don't know I could not do that in the past, it might be a while ago. Anyway thanks for pointing it out.