deal with database schema change version

[bdilly]

https://kernelci.slack.com/archives/C067UJC404A/p1719582659542479

[murilx]

@MarceloRobert check if this still makes sense

[MarceloRobert]

@WilsonNet Do you think that the updates on PR 1110 are enough to cover the needs here? I think you may have a bit more context on the original intention of this issue. But IMO that PR does close this issue

[MarceloRobert]

We have to add a bit more description and documentation about actions when the schema changes, but no other code is required now

[tales-aparecida]

Can we close this?

[MarceloRobert]

I think we still need some quick documentation, no code

[tales-aparecida]

So kind of #1783?

[MarceloRobert]

Kind of, but 1783 is about sending discord messages of migrations, this is another topic

[alanpeixinho]

@tales-aparecida do we still have the context on which docs are missing here?

[tales-aparecida]

@tales-aparecida do we still have the context on which docs are missing here?

I'm unsure.

Kind of, but 1783 is about sending discord messages of migrations, this is another topic

@MarceloRobert , did we ever refined the documentation requirements?

[MarceloRobert]

@tales-aparecida I don't think so. But as far as I remember this is about adding instructions on what to do in case there are conflicting schema changes.

Of course this issue was created when we didn't have control over it, but I guess this is for times like what happened recently with the lab table/field, where @alanpeixinho had to add a bunch of "TODO"s to remove the fallback once all data was updated to the new format (having their lab in the lab field).

The main thing is: in case we want to change the schema in a backwards-INcompatible or conflicting way, what should we do?

[MarceloRobert]

I really don't think it has to be a full "procedure" or anything automatic or fancy. Just mention in the docs what we are currently doing

[alanpeixinho]

I am not even sure the approach we are doing for labs is a proper approach for different scenarios.
In the specific case of #1968 we are doing a dual write on the ingester. But I am afraid this might be a case-by-case scenario.

[MarceloRobert]

@alanpeixinho There's also the example of https://github.com/kernelci/dashboard/pull/1110/changes when we had to change from build valid (a bool) to build status (an enum like in the tests table). I believe that structure of "get schema version" is still in place.

The point is not to improve the current way we are doing things, but rather to just document it instead of keeping them in comments and in our own knowledge. Even if it is case-by-case, we could list the solutions we had so far and add a note that they may not be the most optimal.
We can improve the "schema change pipeline" later, for now IMO we can use this issue just to document the approaches and start over a new issue with the ideas on how to improve all this later.