Modeling structures that are mostly (but not completely) records

[aabs]

Hi, Apologies for the noobie question. I'm still trying to find my feet with typespec.

I'm dealing with a 3rd party telemetry API that delivers responses like this, and I'm unsure how to model it with typespec:

I figure I can use a Record<> to represent the contents of result_data, but in every case the items that sit under record fields like 1370462_1_1_1 are a whole bunch of different fields with keys (starting with p), plus a time_stamp field. I guess I could just go ahead and make that a Record<string> and then cast to double or DateTime on receipt.

Is this possible/acceptable?

model AssetTelemetry {
  ...Record<string>;
  time_stamp: string;
}

How could I model a structure like this (idiomatically)? FWIW, In practice this will be a very large payload with many records, and many data points beneath the records.

[bterlson]

Yeah spreading of a record is acceptable and is the preferred way to represent this kind of thing where you have a known properties and then a bunch of unknown properties. So to me that looks like:

model Result {
   result_code: string;
   // etc.
   result_data: Record<ResultData>
}

model ResultData {
  ... Record<string>;
  
  time_stamp: string;
}

That is a strange timestamp format I have never seen before. Does it have a name?

[bterlson]

It's such a near miss, just add a T and a Z (assuming this represents UTC) and it's ISO8601 basic format 😁

[aabs]

UTC? What's that? 😆

[baywet]

Thanks for the additional information. Kiota adds an additional data dictionary/record (string:object) property to models, but it's a convention from kiota itself. It doesn't do anything with the additional properties information from the OAS description.
I hope that clarifies things!

[bterlson]

@baywet that means, I think, that while the additionaProperties openapi is effectively ignored, the API should be usable regardless via the additional data dictionary?

[baywet]

correct

[aabs]

Thanks for the additional information. Kiota adds an additional data dictionary/record (string:object) property to models, but it's a convention from kiota itself. It doesn't do anything with the additional properties information from the OAS description. I hope that clarifies things!

Do you mean that, because there is a catch-all definition in there, the explicitly named property is ignored?

[baywet]

To be more specific, this is what I'm saying is ignored.

additionalProperties:
        type: string

additionalProperties:
            type: array
            items:
              $ref: '#/components/schemas/AssetTelemetryRecord'

The other properties/types should be generated for you.

[aabs]

Thanks. That is a little problematic for me when it comes to deserializing elements of type AssetTelemetryRecord. This definition is the only use of that type, so it doesn't get generated by default.
Of course I can create some sort of Dummy API endpoint that references the type, so I have it around, but it feels contrived to do that.

[baywet]

We could imagine adding support for projecting additional properties schema to a type, and make sure it does not get trimmed by the generator because it's "unused". This would be a stopgap to supporting pattern properties, once the parsing library we use actual supports OAS 3.1.
Can you create an issue at https://github.com/microsoft/kiota please?