Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Parquet IO: improve ProteinIdentification identifier architecture

Ouverte
  • Quelque chose ne va pas ?
#9,401 1 commentaire 1 réaction 2 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@jpfeuffer y travaille déjà.

Depuis le 24/5/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

This issue is to track some potential improvements we should also land in the xml format path.

Context

PR #9400 closes two real gaps in the parquet IO layer by bringing identifier handling to parity with the XML lane (load-side synthesis via UniqueIdGenerator, store-side uniqueness check). That's the right pragmatic fix, but the underlying architecture has some design debt — shared with the XML lane — that's worth addressing in a future parquet schema revision.

Current design

  • The run_identifier string serves dual duty: it's the internal join key linking PeptideIdentification → ProteinIdentification, and it's the semantic "run identity" used by tools like IDMerger / IDRipper to decide what to collapse or split.
  • On every load (XML and now parquet), the identifier is synthesized as <search_engine>_<date>_<UniqueIdGenerator::getUniqueId()>. Two loads of the same file produce different in-memory identifiers for the same data.
  • Identifier synthesis lives inside the IO layer (IdXMLFile::load, PSMArrowIO::importFromParquet, etc.), meaning deserialization mutates domain objects.

Proposed improvements

1. Deterministic content-based identifiers

Replace the non-deterministic UniqueIdGenerator::getUniqueId() suffix with a hash of the run's invariant properties (search engine, search parameters, input file paths, date). Benefits:

  • Two loads of the same file yield the same in-memory state → reproducible, debuggable
  • Collision resistance comes from content, not randomness
  • Downstream tests no longer need to mask identifier suffixes
2. Separate internal join key from run identity

The parquet schema could use a structural join key (integer index or row position) for the internal PeptideIdentification ↔ ProteinIdentification linkage, and carry the human-meaningful run identity as a separate column. This eliminates the need for rename maps and re-stamping during deserialization — the join is positional, not string-based.

3. Move identifier management out of the IO layer

IO should faithfully round-trip what's stored. Collision prevention belongs in the operations that actually create collisions: IDMerger, IDRipper, or a shared utility called at the tool level (e.g., ensureUniqueRunIdentifiers()). The IO layer would just deserialize; merge/split tools would call the uniqueness logic before combining data from multiple sources.

Trade-offs

  • All three are breaking changes to the on-disk format and tool-level contracts, so they'd need to be coordinated as part of a "parquet v2 schema" effort.
  • The current parity-with-XML approach (#9400) is correct for now — it closes real bugs without changing the architecture.
  • Proposals 1–3 are independent and could be adopted incrementally.

Assigning @jpfeuffer and @cbielow for discussion on scope and prioritization.

Langage dominant
C++
Étoiles
623
Forks
441
Merge moyen
23 h 59 min
PR mergées (30 j)
283

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de OpenMS/OpenMS

Toutes les issues de OpenMS/OpenMS

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.