Class GeoCharacteristicKey

java.lang.Object
ubic.gemma.core.loader.expression.geo.GeoCharacteristicKey
public final class GeoCharacteristicKey extends Object
Where a GEO "key: value" characteristic actually divides.

🛑 One place, because there were two and they disagreed silently. GeoConverterImpl split a characteristic into CATEGORY/VALUE and GeoSourceMetadataBuilder split the same string into a blob key, each with its own indexOf(':'). Both cut at the FIRST colon, so a value containing one was divided inside itself, and the two produced separately-wrong copies of the same mistake — the stored characteristic CATEGORY "cervical cancer (post chemotherapy", and the blob key "gender (m" on GSE205450 (frinkbro, 2026-09-11). A second copy of a parse is a second place for it to be wrong; put the rule here and call it.

The rule

A category is a short label the submitter chose, so the separating colon is the first one whose key half stands on its own — brackets balanced. An unbalanced ( means the colon was inside a parenthesised aside, which is frinkbro's signature for the defect, and scanning on to the next candidate rather than giving up recovers the real key: "cervical cancer (post chemotherapy: TP 2cycle): IIB" divides at the second colon.

⚠️ Deliberately NOT rejecting a key containing =. Legend keys legitimately carry them — "lithium use (non-user=0, user = 1)" is a real category pinned by GeoCharacteristicParseTest — and rejecting it sent the string on to the = split, which truncated it at the first =. That traded one bug for another; bracket balance alone covers the legend family.

Author:
gembro

  • Method Details

    • split

      public static String[] split(String field)
      Divide at the separating colon, which is not always the first.
      Returns:
      two elements when a separating colon was found, otherwise one holding the input