Nimbus method implented in the API does not save duplicate solutions to the database

[juropo]

What is the current behavior?
The current API implementation does not save duplicate solutions to the database, i.e. if the method finds a solution that already exists in the database, the new solution is not added to the database. Instead, the old solution that is already found in database is marked as a current one and returned to the webui.

Describe the solution you'd like
I would like to not change how the solutions are saved to the database currently, because it makes it very easy to ensure that duplicate solutions are never returned to the webui without having to comb through the whole database for duplicates at every method iteration.

However, as Bhupinder pointed out, this solution has the issue that we lose the ability to reconstruct the user's actions, because every new generated solution is not saved. Instead of changing how solutions are saved, I propose we solve this problem by adding logging to a different table entirely. If we, for example, just store the id:s of the returned solutions and preferences (with timestamps), this would produce a much better description of user actions than the solution_archive table ever could.

Describe alternatives you've considered
If Nimbus instead stores the generated duplicate solutions into the solution_archive, then we would need a different solution for dealing with the duplicates, so that they are not shown in the webui. Potential solutions include.

• Going through the whole solution at every iteration and making sure no duplicates are returned/shown. (Computationally expensive.)
• Adding a new column to solution_archive to denote duplicate solutions, so that they can easily be filtered out. (Would add method specific stuff to solution_archive, which I think we agree is bad.)
• Keeping a list of duplicate solutions/storing NIMBUS solutions in a different table. (Seems needlessly convoluted.)

So yeah, I don't really like the alternatives.

[juropo]

Discussed this with Bhupinder a bit, and it seems like the solution we are going with is adding a column to solution_archive to mark duplicates.

[juropo]

It seems like the issue is more complicated than that. Apparently the method is supposed to write to 4 different tables (plus maybe log) at every iteration. That seems dumb.