Issue with generating types from json payload with special character field names

[KCSAbeywickrama]

Description

While trying to generate Ballerina types from a valid JSON payload with special character field names, certain field names in the JSON result in invalid Ballerina identifiers.

For example, this part is extracted from a GitHub issue event payload,

{
  "total_count": 0,
  "+1": 0,
  "-1": 0
}

When generating a Ballerina record type, the output looks like this,

type Reactions record {|
    int total_count;
    int +1;
    int -1;
|};

However, +1 and -1 are valid JSON keys, even though they are invalid Ballerina identifiers

Steps to Reproduce

Use the given sample payload

Version

1.2.25080717

Environment Details (with versions)

No response

[dulajdilshan]

Option 1:
We need to keep a generated name for field name and have the special-charactered name under the @jsondata:Nameannotation.

Ref: https://central.ballerina.io/ballerina/data.jsondata/latest#Name

{
  "total_count": 0,
  "+1": 0
}

import ballerina/data.jsondata;
type RecordName record {
    int total_count;
    @jsondata:Name {
        value: "+1"
    }
    int positive1 // generatedName
}

Option 2:
We can escape the character with /.

{
  "total_count": 0,
  "+1": 0
}

import ballerina/data.jsondata;
type RecordName record {
    int total_count;
    int /+1;
}

Let's evaluate the pros and cons and go with an option.

[samithkavishke]

As discussed offline with @sm1990, we will go with the second option since it reflects the user-defined structure accurately. The first option also makes it difficult to generate a meaningful argument name that works for all cases.

[dulajdilshan]

As discussed offline with @sm1990, we will go with the second option since it reflects the user-defined structure accurately. The first option also makes it difficult to generate a meaningful argument name that works for all cases.

Ack. Let's go with option 2.

[dulajdilshan]

When we use Option 2, the UI ends up showing escaped characters (e.g., \) because the original field name is not available in the model.
Introducing the @jsondata:Name annotation resolves this issue by preserving the original name, which the UI can be improved to read and display correctly.

The only complexity arises when editing an existing type. In such cases, if the user updates a field name, we can assume that the preserved original name is no longer required. Therefore, the annotation can be safely removed upon update.

Based on this, we will proceed with a combined approach:

• Use Option 2 together with the annotation,
• Remove the annotation automatically when the field name is edited.

cc: @sm1990

[dulajdilshan]

When we use Option 2, the UI ends up showing escaped characters (e.g., \) because the original field name is not available in the model. Introducing the @jsondata:Name annotation resolves this issue by preserving the original name, which the UI can be improved to read and display correctly.

The only complexity arises when editing an existing type. In such cases, if the user updates a field name, we can assume that the preserved original name is no longer required. Therefore, the annotation can be safely removed upon update.

Based on this, we will proceed with a combined approach:

• Use Option 2 together with the annotation,
• Remove the annotation automatically when the field name is edited.

cc: @sm1990

@samithkavishke let's work on the implementation adhering to this.