Invalid value path 'Building<*> ID' at 9 for type CanonicalXYZ


#1

I’ve a canonical type defined as follows:

type CanonicalXYZ mixes Canonical<CanonicalXYZ> {
  @ser(name="Building ID")
  buildingId: string
  . . .
}

Now I’m using ser annotation to map what’s been uploading in the CSV to the right field, Here is an example of the CSV data I am expected:

TagName,Building ID,Units,Energy,Description,Measurement
ID1,1,Unit1,Energy1,ABC1,Measurement1
ID2,1,Unit2,Energy2,ABC1,Measuremen2

The problem is when I upload data, it fails with this error:

 Invalid value path 'Building<*> ID' at 9 for type CanonicalXYZ
 c3.love.exceptions.C3RuntimeException: Invalid value path 'Building<*> ID' at 9 for type CanonicalXYZ
 at c3.love.typesys.ValuePath.formatError(ValuePath.java:278)
 at c3.love.typesys.ValuePath.parse(ValuePath.java:270)
 at c3.love.typesys.ValuePath.parse(ValuePath.java:78)
 at ...

Is there another option to map the field name in the CSV to its name in the canonical file?


#2

Hi Bachir,
Spaces are not accepted in field names at the moment.


#3

The fields in a type become variables or attributes in an object. Variables can not be defined with spaces in many programming languages. The fields in a persistable type also become a column names in the database. Many database systems don’t allow spaces in the column name. Therefore, spaces in the field will most likely never supported.


#4

You guys are missing the point, there is no type with a field such as ‘Building ID’, instead this annotation @ser indicates that when SERIALIZING a type to csv/xml, to use ‘Building ID’ in that text representation of an instance of a type.

I think this is either a missing feature or a bug.


#5

thanks @rileysiebel, I remember seeing in the documentation that @ser is for serialization, which could be confirmed with

> CanonicalXYZ.csvHeader()
"buildingId,.."

I thought it could also works for de-serialization.


#6

@bachr i think it SHOULD work the way you want it to. There should be a way to do what you’re trying to do, i’m just not sure what that way is.


#7

The spaces in column names should be escaped, either before the import or during the import.
EDIT: My previous quote was ambiguous.

By escaping I mean any function from alphabet X to alphabet Y where Y is not a superset of X, i.e., Y does not contain (i.e., cannot handle safely) some characters of X. You pick one character u from Y and call it the escape character, and the remainder is called Z. Each character c in X that is not in Z, as well as character u itself if it is also in X (i.e., c is in X\Z), becomes escaped as uc' where c' is in Z', a subset of Y of the same size as X\Z, and mapping u: Z' -> X\Z is bijective (I use u for both the escape character and the unescape function), so there is the inverse escaping function, e: X\Z -> Z' (sorry for the unintuitive naming).

This is a systematic way to tunnel problematic characters through “an unsafe environment”. However, it is rarely used properly, and that is why spaces and similar characters should be avoided.


#8

Space doesn’t work in all scenarios. Please avoid using space in any field name otherwise you are begging for trouble down the road.


#9

I agree that it should be avoided. Regardless, it can be handled when importing CSV into C3, if there are no other possibilities.