Entity type reserve word: "case"

I’ve been working on data integration for a few days on 7.9.0 and ran into this issue that was incredibly nuanced and challenging to debug. This problem is relevant in the context of a customer application. Though it can be worked around, I wanted to raise the issue to see if there are other circumstances like this that could cause an issue.

When I define an entity type with an arbitrary attribute (plus the requisite Canonical/Transform) as shown below, I can provision and successfully load data by cURLing a CSV to the Canonical’s /import API.

type CanonicalSimpleType mixes Canonical<CanonicalSimpleType> {
    Case: string
}
type TransformCanonicalSimpleTypeToSimpleType mixes SimpleType transforms CanonicalSimpleType {
    arbitraryAttribute: ~ expression "Case"
}
entity type SimpleType schema name "SIMPLE" {
    arbitraryAttribute: string
}

However, when that entity type’s arbitrary attribute is called “case”, like so, I experience a problem.

type CanonicalSimpleType mixes Canonical<CanonicalSimpleType> {
    Case: string
}
type TransformCanonicalSimpleTypeToSimpleType mixes SimpleType transforms CanonicalSimpleType {
    case: ~ expression "Case"
}
entity type SimpleType schema name "SIMPLE" {
    case: string
}

I can successfully provision this configuration, but when I try to load data to the /import endpoint, I receive a runtime exception in my file loading process with the following:

Invalid expression "[case,{meta:[updatedBy,sourceFile,updated]}]": syntax error (<expr>#1)

From what I can glean, it seems that somewhere in the post-transform upsert/persist process, an expression parse is called on the list of attributes/columns (persistable type-side, not canonical-side) and “case” is being identified as a keyword - though obviously incorrectly, since this isn’t meant to be JavaScript. Is this behavior intentional? Are there other keywords I should know about?

Footnote… The error message is misleading to a user trying to load data (i.e. “I didn’t try to make an expression with this syntax, where did this come from?”). While it’s relatively easy to see the problem in this trivial example, it’s incredibly subtle when I’m trying to load a file with 200 columns and have little idea what or which is causing the issue (e.g. “Is my environment configured correctly?”, “Does my file have an error?”, “Is my transform correct?”, etc.). Typical data integration debugging yielded no firm answers, and only a column-by-column attempt at loading the marginal records led to a root cause.

I also have the set of files used to produce this behavior if anyone wants to confirm/debug it.

Nice bug.

As you may have figured out it is not supported to use javascript reserved words as field names. http://es5.github.io/x7.html#x7.6

Currently, there is no validation for this, but i have filed an improvement ticket to make sure this is caught in the provisioning layer.

Thank you for catching this.

2 Likes