The current concept of "snapshot" in SQ is overcomplicated and so error-prone for the following reasons :
- There is one snapshot per component in a project. So by design in a project containing 200 hundreds source files, we have one snapshot for each source file and those snapshots can have different times. Whereas, we should have only ONE snapshot for ALL the components of a project and this snapshot should have a functional name : an analysis.
- When the concept of snapshot was introduced, modules were considered as sub-projects and so source files inside a module are not attached to their root project but to their module. As a consequence there is no global tree of components but one tree of components per module and a tree of modules at project level -> this highly increases the complexity to request the overall tree of components
- Scope, qualifier, and paths (inside the tree of components) are duplicated in the 'PROJECTS' and 'SNAPSHOTS' tables -> For a new joiner, it's impossible to know which and when a column should be used
- When computing a new report, we're creating and deleting one row in the SNAPSHOTS table for each component of the project whereas most of the time a small percentage of the structure of the project evolve during two analysis
- The path of components is based on SNAPSHOT_ID instead of being based on COMPONENT_UUID -> so this requires first to create all the snapshots and only then to build/update their paths.
Here is a way to fix all those limitations :
- Renaming table "PROJECTS" to "COMPONENTS"
- Managing the path of components inside the "COMPONENTS" table and based on COMPONENT_UUID
- Replacing the SNAPSHOTS table by an ANALYSIS table containing one and only one row for each new integrated report
- Replacing the column PROJECT_MEASURES.SNAPSHOT_ID by PROJECT_MEASURES.COMPONENT_UUID and PROJECT_MEASURES.SNAPSHOT_ID by ANALYSIS.SNAPSHOT_UUID
Compute Engine has to deal with transactions when inserting or updating the table PROJECTS. The options are:
- rely on standard DB transaction. Can it support dozens of thousands new records when inserting a newly big project ?
- use new columns NAME_B and VERSION_B with temporary values in order to have a single UPDATE request in the same transaction that updates SNAPSHOTS.IS_LAST:
UPDATE PROJECTS SET NAME=NAME_B, VERSION=VERSION_B WHERE PROJECT_UUID=? AND B_UPDATED=true. Note that it works as rows are not deleted but set to ENABLED=false.