OptionalkeyValuePairs: KeyValuePair[]Utility function to check if the composite key has any values set
StaticDefaultDefault delimiter for separating fields in a string that represents a key value pair within the composite key
StaticDefaultDefault delimiter for separating values from field names in a string that represents a key value pair within the composite key
Utility function to return a copy of the CompositeKey with the Value properties as string
a copy of the KeyValuePairs array but with the Value properties as string
Utility function to compare this composite key to another
the composite key to compare against
true if the primary key values are the same, false if they are different
Utility function to compare the key primary key of this object to another sets to see if they are the same or not
the primary key values to compare against
true if the primary key values are the same, false if they are different
returns the value of the key value pair for the specified field name
the field name to get the value for
the value of the key value pair for the specified field name
returns the value of the key value pair at the specified index
the index of the key value pair to get the value for
the value of the key value pair at the specified index
Utility to load the object from a string representation of the key value pairs in the format "Field1|Value1||Field2|Value2" etc. The delimiters between the fields default to '||' and the values default to '|', but can be anything desired.
Loads from a simple object by extracting the key value pairs from the object
Loads the key from a single key value pair
Parses a provided url segment using the provided delimiter and loads the key value pairs from it. If the segment just contains a single value and no delimiter, it will assume the field name is the primary key field name of the entity and load that way.
Parses the provided routeSegment and assumes the field names are included in the segment
The exact inverse of CompositeKey.LoadFromURLSegment. A single-field key serializes to
just its value — the shorthand LoadFromURLSegment maps back onto the entity's first primary
key — while a multi-field key serializes to the full Field1|Value1||Field2|Value2 segment.
A single value that itself contains the value delimiter also gets the full segment; the parsers
(SimpleLoadFromURLSegment, LoadFromConcatenatedString) treat everything after the first
delimiter as the value, so it round-trips rather than being truncated. A value containing the
field delimiter (||) remains unrepresentable — a pre-existing limit of the format.
This is the "compact" record-id form carried by search results, MJ: List Details,
MJ: User Record Logs and Explorer record URLs: for the overwhelmingly common single-column
primary key it is indistinguishable from the raw value, so IN (...) filters, dedup keys and
persisted data all keep working, while composite keys still round-trip losslessly.
Utility to generate a string representation of the key value pairs in the format "Field1|Value1||Field2|Value2" etc. The field delimiter defaults to '||' and the value delimiter defaults to '|'
The canonical serialization of this key for storage in a polymorphic RecordID column — the
payload half of an EntityID/RecordID pair. Always the fully-prefixed
Field1|Value1||Field2|Value2 form, so the string carries its own field names and round-trips
without the reader needing to know the entity.
This is the one encoding MJ writes going forward. It matches what
SQLServerDataProvider already writes to RecordChange.RecordID and what
Metadata.GetRecordChanges reads back; the bare RecordGeoCode form is the outlier and is
read through FromLegacyRecordID until it migrates.
Unlike ToConcatenatedString, this throws rather than emitting a string that cannot
be parsed back: a value containing the value delimiter (|) would re-split into the wrong
field/value boundary on the way in. Silently writing such a value is how a RecordID column
ends up holding a key nothing can resolve.
For URL segments, we use | and || as the standard delimiters for field and value respectively in order to avoid conflicts with the standard URL delimiters like = and &. This method converts the key value pairs to a URL segment
Optionalsegment: stringUtility function to return a string representation of the composite key in the format "FieldName=Value AND FieldName=Value"
if true, will return "FieldName IS NULL" for any key value pair that has a null or undefined value, if false, will return "FieldName=Value"
a string representation of the composite key in the format "FieldName=Value AND FieldName=Value"
Helper method to check if the underlying key value pairs are valid or not i.e. if any of the key value pairs are null or undefined
Optionalentity: EntityInfoIf provided, this method will validate that the composite key is valid for the given entity as a primary key or alternate key.
If set to true, and entity is provided, this method will validate that the composite key is valid as the primary key for the given entity.
true if all key value pairs are valid, false if any are null or undefined
a copy of the KeyValuePairs array but with the Value properties as type string
StaticEqualsUtility function to compare either single composite keys or arrays of composite keys. When comparing arrays, both order and content must match.
First key or array of keys to compare
Second key or array of keys to compare
true if the keys are equal, false otherwise. Returns false if types don't match (single vs array).
StaticFromStatic form of LoadFromEntityInfoAndRecord: builds the key from a data row (a
ResultType: 'simple' RunView row, or any object keyed by field name) using the entity's
actual primary key column(s). Pair with ToCompactURLSegment to produce a record-id
string that FromURLSegment reads back for any entity, single- or multi-column key.
StaticFromMany entities have a single primary key field called ID, this utility method allows you to create a CompositeKey from just that ID value.
StaticFromStatic factory method to create a CompositeKey from a single key value pair.
StaticFromStatic factory method to create a CompositeKey from an array of key value pairs. Mirrors the constructor but allows for a more explicit creation of a CompositeKey from an array of KeyValuePair objects.
StaticFromReads the transitional bare-value RecordID form: a single primary key value with no field
name (38CB433E-…), or a composite written as values only (val1||val2).
Only RecordGeoCode writes this, via GeoCodeSyncService and the matching T-SQL in the
base-view generator. It exists so the two hand-rolled sniffers (recent-access.service.ts,
record-tags.component.ts) can be replaced by one named function whose name says it is
temporary — and it is deliberately separate from FromRecordID so that "I am reading a
legacy encoding" is a decision at the call site rather than a guess inside the parser. Delete
it once RecordGeoCode is re-encoded.
Field names come from entity.PrimaryKeys positionally, because the stored string does not
carry them. That is exactly why the format is being retired: position is not a contract, so a
primary key column reorder silently remaps the key.
StaticFromCreates a CompositeKey from a simple object where the keys are the field names and the values are the values.
StaticFromReads a canonical RecordID string (see ToRecordID) back into a key, validated
against the entity it is supposed to belong to.
This is deliberately not a rename of LoadFromConcatenatedString, which cannot signal
failure: given a string with no delimiter it leaves KeyValuePairs empty and returns
normally, so every caller has to sniff the string itself to find out whether the parse
happened. That is the defect behind the two hand-rolled sniffers in shared Angular code, and
it is why a legacy bare composite (val1||val2) silently parses into phantom pairs with
garbage field names instead of being rejected.
The field-name check is what makes that safe: val1||val2 parses cleanly as a shape, but
produces field names the entity does not have, so it is caught here rather than reaching the
database as a key that matches nothing. A string with no delimiter at all is accepted only for
a single-column primary key, where it is unambiguous, and takes its field name from
FirstPrimaryKey — the same fallback LoadFromURLSegment already uses.
the entity the record id belongs to; its PrimaryKeys define the expected shape
the stored RecordID value
StaticFromStatic form of LoadFromURLSegment: builds a key from a record-id string that is either a
bare value (a single-column primary key, mapped onto entity.FirstPrimaryKey whatever that
column is called) or a full Field1|Value1||Field2|Value2 segment (a composite primary key).
It reads both the compact form produced by ToCompactURLSegment and the always-prefixed
form produced by ToURLSegment.
Use this — not FromID — whenever the entity is a variable rather than a literal MJ
core entity name. MJ supports primary keys with any column name(s) and type(s); hardcoding
ID fails Load() with "Primary key ID not found in entity ..." for every entity whose key
is called something else, and can never represent a multi-column key at all.
When entity is null/undefined (metadata not resolvable) a delimited segment is parsed as-is
since it already carries its field names, and a bare value falls back to an ID key so callers
on an unknown entity keep the pre-existing behavior instead of throwing.
Composite keys are used to represent database keys and can include one or more key value pairs.