start hashing conditions content

[rlcee]

When conditions content is saved, also write a content hash. This allows efficient cat3 online/offline processing. cat3 are tables which are in DbService format and may or may not be modified by the online experts for any given run. A good example is a bad channel list. Since the content may or may not change, when we need to copy the online content offline, we can hash the content and easily look up if an exact copy of the table has already been stored offline. If it has, we use that copy. If the hash doesn't match, then we can create the new content offline.
The dev and prd databases have the new column. It will be ignored by old code, which should continue to work fine. The new code will always commit the hash value, and will be able to look up by hash.

[FNALbuild]

Hi @rlcee,
You have proposed changes to files in these packages:

• DbTables
• DbService

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

⌛ The following tests have been triggered for 849985e: build (Build queue - API unavailable)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at 849985e.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged 849985e at e8de2a4
build (prof)	✅	Log file. Build time: 04 min 17 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	✅	Log file.
check_cmake	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 2 files
clang-tidy	➡️	1 errors 325 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at 849985e after being merged into the base branch at e8de2a4.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[oksuzian]

I'll review the PR to find potential issues.The user wants to find issues in this PR. Let me look at the actual changes.Here's a focused review of potential issues in PR #1891 – "start hashing conditions content".

Summary

Adds a chash (content hash) column to val.calibrations so conditions tables can be de-duplicated by content. Changes span SQL schema, DbTool, and the ValCalibrations DbTable row model. 34 additions / 16 deletions across 4 files. Low–medium risk, but a few concrete issues stand out.

Issues found

1. SQL injection / unescaped hash in INSERT (medium)

In DbTool.cc, the hash is concatenated directly into the SQL string:

command =
    "INSERT INTO val.calibrations (tid,chash,create_time,create_user)  VALUES (" +
  std::to_string(tid) + ",'" + ptr->hash() +
  "',CURRENT_TIMESTAMP,SESSION_USER) RETURNING cid;";

If ptr->hash() ever contains a ', the statement breaks (or is injectable). A hex/base64 digest is safe in practice, but this assumes the hash format is always sanitized. Worth a comment asserting the hash charset, or use a parameterized/escaped value for robustness.

2. refresh() moved from private to public but no functional link (low)

DbTool.hh moves the refresh() declaration (and its comment) from private to public. Confirm this is intentional and that the method is actually needed publicly by the new hashing/commit flow — the diff doesn't show a new caller, so this may be an orphaned change. Also note clearResult() is added but I don't see a caller in this diff.

3. Backward/format compatibility of CSV & column order (low–medium)

ValCalibrations now emits/parses a 5-column layout (cid,tid,chash,create_time,create_user). Any previously exported CSV or cached val.calibrations content with the old 4-column format will fail in addRow() (columns[4] out-of-range / std::stoi) when read by the new code. The PR body says old code ignores the new column, but the reverse — new code reading old-format data — isn't addressed. Worth confirming there's no persisted 4-column data path.

4. Empty-hash guard returns error only at commit (low)

The new guard in commitCalibrationList rejects empty hashes:

if (ptr->hash().empty()) {
  std::cout << "DbTool::commitCalibrationList found empty hash summary ..."
  return 1;
}

Good, but this is the only enforcement. The SQL DEFAULT '' means rows with empty hash are still schema-valid, so lookups-by-hash could silently match empties. Consider whether chash should be NOT NULL DEFAULT '' vs. disallowing empties at the DB level.

[rlcee]

1. true, but hash is internally generated, not user defined, users are strictly authorized, there is no valuable information in the db, etc.
2. this is intentional, requirement out of this scope
3. there should be no issue here in any use pattern
4. designed pattern
   ready to proceed