The generators should add the model name and the Rosetta version used when creating the codebase

[dschwartznyc]

Description

The code generated from Rosetta definitions lacks the context of which model it represents and which version of the Rosetta definition was used to create the generator. As a result, the data exchange between users of the generated code is limited. The consumer of data does not necessarily know what type or version of the generated code to use.

Describe the solution you'd like

Could you add the model name and version to the generated code? The model name should be fully qualified and the version number should be consistent with release names.

Describe alternatives you've considered

N/A

[minesh-s-patel]

@dschwartznyc Totally agree with this. thanks

[dschwartznyc]

@minesh-s-patel @tomhealey-icma @chrisisla @brianlynn2

This change is likely to be a breaking change. I think the advised approach would be to add the class (model name) and version as meta or type data and move the main collection of information to a subordinate element (something like “payload”).

IE the layout of the revised JSON would be something like:

{
	“type”  :  {
		"modelName" : “cdm.event.common.TradeState”,
		“version” : “4.2.0”,
	},
	“payload” : {
		meta" : {
			"globalKey" : "d128fe6f"
  		},
  		"trade" : {
			"account" : [ {
				"accountBeneficiary" : {
					"externalReference" : "p1",
					"globalReference" : "7cec034c"
      				},
…
}

Since adding the model’s name and version would be a breaking change, I’d suggest that we include it in the next major version (5). Thoughts?

NB, from a Python perspective the change is quite simple and only entails an update to the runtime utilities included with the package (not the generation process itself).

[brianlynn2]

The JSON doesn't generate itself; you need to call something to generate it. Can't we change how we call that (e.g. create a new entry point) to create a new way of serializing the CDM model into JSON that has a wrapper similar to what you describe? And similarly for deserializing that wrapped CDM JSON. The new serializer and deserializer wouldn't have to be backward compatible with anything, since they are new.

In other words, rather than changing the existing code, couldn't we add a new functionality for serializing and deserializing with a wrapper?

Or am I missing something?

[dschwartznyc]

For Python and perhaps Java, the change will be to the serializer / de-serializer. The issue is that the contents of the serialization will change in, arguably, a way that breaks how the current code may be producing / consuming the JSON. From: brianlynn2 ***@***.***> Date: Friday, September 15, 2023 at 3:55 PM To: REGnosys/rosetta-code-generators ***@***.***> Cc: dschwartznyc ***@***.***>, Mention ***@***.***> Subject: Re: [REGnosys/rosetta-code-generators] The generators should add the model name and the Rosetta version used when creating the codebase (Issue #251) The JSON doesn't generate itself; you need to call something to generate it. Can't we change how we call that (e.g. create a new entry point) to create a new way of serializing the CDM model into JSON that has a wrapper similar to what you describe? And similarly for deserializing that wrapped CDM JSON. The new serializer and deserializer wouldn't have to be backward compatible with anything, since they are new. In other words, rather than changing the existing code, couldn't we add a new functionality for serializing and deserializing with a wrapper? Or am I missing something? — Reply to this email directly, view it on GitHub<#251 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADD3X6GMBGVCEVFWNQYI5BLX2SXCRANCNFSM6AAAAAA4PIQ7E4>. You are receiving this because you were mentioned.Message ID: ***@***.***>