Hello all, this is a status update on QueryC++ and an apology; I will start with the latter.

If you go to QueryC++’s Gitlab repository, you will see that the repository seems a little abandoned. There have been very few commits with minimal contribution from my end. There is an explanation for this, which I will provide now, followed by an apology. In mid to late 2022, a company contacted me about QueryC++; the company wants to remain nameless. They want to provide a developer who would spend 25% of the developer’s time working on QueryC++. I was very excited, I met with the developer, and I deemed the developer more than able to lift QueryC++ from just my project to a potent tool. It was agreed the developer would start working on QueryC++ in March of 2023. One month ago, I realised work had not started, which confused me. I got a little angry because I expected the company to continue the work in the repo and not make a fork. At least, this was what was agreed upon. In April, I contacted the company to find out what had happened (As I explained on Mastodon. Unfortunately, the developer fell sick with no quick recovery, and the company forgot to contact me, which is understandable. Sadly, this led me to contemplate if I should continue working on QueryC++ or abandon the project, and it has taken a while for me to conclude. Even though I promised that I would continue on Mastodon, which made me feel even worse. However, QueryC++ is important and can give many C++ developers an excellent way to work with SQL queries! Therefore, I have decided to spend more time on QueryC++ than I have been doing. I apologise for the limbo I have left the QueryC++ in, for the lack of information, and for promising something I might have gone back on. This will not happen again. In the future, I will provide clear information about the direction of QueryC++ and find better ways to get others involved.

So where does this leave QueryC++? Well, the fact that a company offered to provide a developer should tell you that it is used. In fact, it is used in production, which I am thrilled about. But what are the next steps? Well, the next steps are as follows:

  1. Focusing only on CMake
  2. Hardening the test process
    • Automatic integration test
    • Automatic unit test
  3. Better Documentation

Focusing only on CMake

From the beginning, I planned to provide QueryC++ with out of the box support for Waf, CMake, and Make. However, there are a few things that could be improved with this. First, maintaining three build systems is a pain in the buttocks. Secondly, I would like QueryC++ to be as self-contained as possible, meaning no external dependency management for the user. In my opinion, both Waf and Make fail phenomenally, with only CMake providing something nice like FetchContent. I am aware that Steinwurf ApS. provides a customised version of Waf, but I want to avoid introducing a custom version of a build system. Additionally, the more I have been looking at open-source projects, the more I realise how widespread the usage of CMake is. Finally, on this topic, I have been thinking about switching to xmake, but I have yet to see it shine. I have not seen the benefit of xmake over CMake, nor is anyone making the switch. I know of one project that attempted a switch but gave up, which does not present xmake in the best light.

Hardening the test process

First, what am I talking about? Right now, I have to run the unit tests manually to verify that things work before pushing, a thing which I need to remember. Therefore I would like to set up pipelines properly on Gitlab to ensure errors do not make it into QueryC++. This extends to the integration test, where I am currently working on making an integration test that tests query syntax and executes them against a PostgreSQL database. I want to thank Tibold Kandrai, CTO at Estaldo, for sparing and helping me set up a test Docker environment. The goal here is to reduce the potential amount of bugs and increase the trust level of QueryC++.

Better Documentation

Good documentation, even though people never read it, is vital for a library. Be it comments in the source code, examples, or a user manual. Right now, the documentation of QueryC++ is very segregated and not the best. Therefore, I would like to add more examples and a user manual using mdbook. This will lift the documentation of QueryC++ and make it more approachable.

Focus on Features

Right now, I would like to work on the above first before adding more features. However, I will add more and more features for PostgreSQL and, hopefully, MariaDB soon. But right now, the focus is more on the project’s structure.

Funding

Currently, QueryC++ receives no funding. At the moment, that is not a problem, but it may become in 6-8 months. Therefore, I will set up a Liberapay or alternative donation options. The reason for this is I will need to allocate some hardware for long-term testing, which I need access to right now.

I would like to invite all to provide suggestions for a QueryC++ log!

That was all for this time. I hope to give more regular updates from now on!

./Lars