Port `network_peers` to the database generator

[stgraber]

Incus uses a built-in code generator for most of its database interactions.
Unfortunately not all entities have yet been moved over to that mechanism, causing us to have far more SQL code in our code tree than we'd really like.

The goal here is to define new code generated functions in internal/server/db/cluster/ and then remove the old implementation from internal/server/db/ transitioning everything over to the new generated functions.

A recent example of the database generator being used can be found here:
#655

Note that some of the syntax has since evolved, so you may want to look at the current version of networks_integrations.go to see how to invoke the generator.

[NathanChase22]

Hey @stgraber , I'm a UT student having to contribute to an open source project for Professor Chidambaram's Virtualization course. I am interested in this issue, but I would like to know more about the issue first before taking it on.

From my understanding, we are refactoring the code to use a built-in interface to create databases, is that right?

[stgraber]

Yeah, that's right. We're moving away from hand written database code over to programmatically generated code. We've been in an in-between state for a number of years now and that's making working on the code a bit annoying.

So we're now looking at moving a bunch of the remaining bits, starting with those that follow a pretty common pattern over to the generated code.

Basically the way I'd normally approach this is:

• Add a basic new setup in internal/server/db/cluster/ based on what's been done for network_integrations for example
• Run make update-schema to generate all the new functions (.mapper.go files)
• Remove the old DB code (in this case internal/server/db/network_peers.go)
• Build the code again and deal with the failures. It will fail to build on every place that was calling the old logic. All of those need to then be updated one by one to use the new generated functions.
• Send the PR and hope all the tests still clear, if not, track down the failures until things are green again.

[NathanChase22]

How much of the code base would you say is dependent on the old DB code? Would we have to adjust any build files like Makefiles to accommodate the new functions?

What sort of tests are currently present for the database? Are we expecting no change to the end behavior after migrating?

It looks like that this issue is similar to some of the other issues, how much variation is there between this issue and say #1802 in the approach?

[stgraber]

We've opened an issue for each of the current files but the general approach and work needed to resolve it should be near identical from one to the next.

There usually isn't any changes needed to the Makefile or anything there.
It's really about changing all the call sites for the old functions to the new functions.

The tests should all be at a higher level than this, so no changes should be needed to the tests, but they will instead be a good way to ensure that the change didn't introduce any unforeseen regression.

[NathanChase22]

@stgraber Just got back with my professor, we are willing to take on this issue

[stgraber]

Excellent, I assigned it to you!

If you have other team members working on this with you, you can have them comment in here too so I can add them to the issue.

[NathanChase22]

Yes there's also my partner, @oronila .

If we run into any issues setting up the environment, who and how should we contact for questions / help?

[stgraber]

GitHub only lets me add people who commented as assignees (to prevent this being used to spam people).

As for questions and interactions. The best is going to be to comment in here or in the pull request once you have it open. That way I and the other maintainers (and some of the other contributors) will be notified and can help you out.

[oronila]

Hi, I am the other member that needs to be added.

[stgraber]

Perfect, got it assigned to the two of you!