Summary
PatternFieldsController (kview) builds its pattern-authoring "choose a data type" list from TinkarTerm.DYNAMIC_COLUMN_DATA_TYPES's descendants:
IntIdSet dataTypeDynamic = viewCalculator.descendentsOf(TinkarTerm.DYNAMIC_COLUMN_DATA_TYPES);
Those descendants (bare Boolean, Decimal, Float, Double, Long, Array, ByteArray, SignedInteger, UUIDDataType — each with a placeholder "Data type" definition) are a different, disjoint identity family from the one ConceptToDataType.convert(Concept) (dev.ikm.tinkar.terms) actually recognizes — the closed 15-concept set (TinkarTerm.STRING, COMPONENT_FIELD, CONCEPT_FIELD, COMPONENT_ID_SET_FIELD, FLOAT_FIELD, INSTANT_LITERAL, LONG, etc.) that real pattern field declarations use as their dataType tag, and that ConceptToDataType.convert() throws UnsupportedOperationException on anything outside of.
Consequence
If an author picks, say, "Float" from this dropdown, the resulting field's dataType tag is the bare Float concept — not TinkarTerm.FLOAT_FIELD. Any later code path that calls ConceptToDataType.convert() on that field's declared dataType (to resolve its FieldDataType for serialization/interpretation) will throw, since bare Float isn't one of the 15 recognized identities.
There's also a disabled filter directly above the call (// .filter(p -> DATA_TYPE_OPTIONS.contains((EntityFacade) Entity.getFast(p)))), suggesting this was already flagged as needing reconciliation and left mid-fix.
Where
komet/kview/src/main/java/dev/ikm/komet/kview/mvvm/view/pattern/PatternFieldsController.java (live, non-test code)- Similar pattern in
komet/application/src/test/java/dev/ikm/komet/app/test/DataTypesViewModelTest.java
Suggested fix
Either:
- Point the dropdown at the
ConceptToDataType-recognized family instead of DYNAMIC_COLUMN_DATA_TYPES's descendants, or
- Re-enable/complete the commented-out filter so only
ConceptToDataType-recognized concepts are offered as choices.
Related
On the ike-starter-set side, DYNAMIC_COLUMN_DATA_TYPES has been reparented under a new Legacy taxonomy branch as a deprecation signal (not a functional change — the concept and its children remain fully resolvable) — see IKE-Network/ike-issues#880. This issue tracks eliminating the disconnected dependency here in kview, which the reparenting alone doesn't fix.
Summary
PatternFieldsController(kview) builds its pattern-authoring "choose a data type" list fromTinkarTerm.DYNAMIC_COLUMN_DATA_TYPES's descendants:Those descendants (bare
Boolean,Decimal,Float,Double,Long,Array,ByteArray,SignedInteger,UUIDDataType— each with a placeholder"Data type"definition) are a different, disjoint identity family from the oneConceptToDataType.convert(Concept)(dev.ikm.tinkar.terms) actually recognizes — the closed 15-concept set (TinkarTerm.STRING,COMPONENT_FIELD,CONCEPT_FIELD,COMPONENT_ID_SET_FIELD,FLOAT_FIELD,INSTANT_LITERAL,LONG, etc.) that real pattern field declarations use as their dataType tag, and thatConceptToDataType.convert()throwsUnsupportedOperationExceptionon anything outside of.Consequence
If an author picks, say, "Float" from this dropdown, the resulting field's dataType tag is the bare
Floatconcept — notTinkarTerm.FLOAT_FIELD. Any later code path that callsConceptToDataType.convert()on that field's declared dataType (to resolve itsFieldDataTypefor serialization/interpretation) will throw, since bareFloatisn't one of the 15 recognized identities.There's also a disabled filter directly above the call (
// .filter(p -> DATA_TYPE_OPTIONS.contains((EntityFacade) Entity.getFast(p)))), suggesting this was already flagged as needing reconciliation and left mid-fix.Where
komet/kview/src/main/java/dev/ikm/komet/kview/mvvm/view/pattern/PatternFieldsController.java(live, non-test code)komet/application/src/test/java/dev/ikm/komet/app/test/DataTypesViewModelTest.javaSuggested fix
Either:
ConceptToDataType-recognized family instead ofDYNAMIC_COLUMN_DATA_TYPES's descendants, orConceptToDataType-recognized concepts are offered as choices.Related
On the
ike-starter-setside,DYNAMIC_COLUMN_DATA_TYPEShas been reparented under a newLegacytaxonomy branch as a deprecation signal (not a functional change — the concept and its children remain fully resolvable) — see IKE-Network/ike-issues#880. This issue tracks eliminating the disconnected dependency here inkview, which the reparenting alone doesn't fix.