Open voxpelli opened 2 years ago
Interesting, thanks for raising the issue! I agree it would be great to have.
An additional benefit could be internally: That it would become possible to validate whether any data is lost in the conversions. Sending a JSON Schema as an input, generating a JSON Schema as an output and checking for substantial differences between the two. A good integration test?
Yes, good point.
I don't think there will be a way to guarantee the output JSON Schema will validate the very same data as the input JSON Schema. In most cases, we can, however with strict validation rules we cannot.
This is because we interpret it from validation rules (which are or can be very strict) to a looser format that only represents the underlying structure. For example, if you have the validation rule such as:
{"type": "string", "format": "email"}
For model generation (at least how it is now) we only care it has the string
type. As email formats are the restriction on the value, not the type in the output language. Maybe in the future, we can support such restrictions 🤔 Related to https://github.com/asyncapi/modelina/issues/130
A complementary feature then could be to take eg TypeScript definitions as input as well (probably a bit complicated) and/or to add JTD as a format for both input and output: https://ajv.js.org/guide/schema-language.html#json-type-definition
A complementary feature then could be to take eg TypeScript definitions as input as well (probably a bit complicated) and/or to add JTD as a format for both input and output: https://ajv.js.org/guide/schema-language.html#json-type-definition
Absolutely, please create another feature request for it, thanks!
Related TS input issue: https://github.com/asyncapi/modelina/issues/187
@jonaslagoni let me work on this since this looks related to #187
Hey @jonaslagoni since we're going to create a new JSON generator, it has to extend AbstractGenerator
and the underlying abstract functions right ? So for starters, I am not thinking of adding preset support or anything right now, just generating a JSON Schema file from the CommonInputModel
.
Also how are we differentiating between generateCompleteModels()
and generate()
for this case ?
Please point out if I have misunderstood anything.
JSON generator, it has to extend AbstractGenerator and the underlying abstract functions right ?
Yes. An important difference between existing generators and a JSON Schema one, is that you only need one, regardless of whether it's an enum, object.
You also don't have any formatting of property names or reserved keywords as everything is wrapped in "
, so on that point, it is easier to implement 🙂
You could take a look at one of the existing PR's that are adding a generator, both examples can be followed in terms of what is needed to add another generator 🙂
Also how are we differentiating between generateCompleteModels() and generate() for this case ?
Good question, I would probably suggest that we use generate
to generate individual JSON Schema documents and generateCompleteModels
could be seen as a bundled schema? 🤔
However, I would only focus on generate
and forget about generateCompleteModels
🙂
How does that sound? 🤔
Sounds good @jonaslagoni. Thanks a lot for clarifying!
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
Is there any update on this? We're trying to use Modelina to resolve all the refs within our schemas, then output them all back to us so we can write them in a flat folder structure. This would be really useful for that I think.
@jonaslagoni at the moment we're just using the ConstrainedMetaModel
output from the TS Generator which gives us the correct dereferenced models. Is there a better way of doing this?
@MattKintonCinch so, you have a x nested JSON Schema file structures, that you want to make flat within the same folder?
@jonaslagoni no worries, managed to get round our specific problem. This would still be a really good feature though, I appreciate the quick response! :)
For anyone looking to get into this issue, we have described how to add new generators here: https://github.com/asyncapi/modelina/blob/master/docs/contributing.md#adding-a-new-generator
Always happy to help you get started, just ping me here or on slack 🙂
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
Is this issue still relevant? I would like to work on this.
@jonaslagoni please lemme know if I should start working on this if not resolved already. Happy to assist in other tasks as well if someone is looking into it.
@akkshitgupta it is yes!
Here is how I would achieve it:
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
Reason/Context
As JSON Schema is a common denominator of all of the input types, being able to take any type of input and output normalized JSON Schema would make this tool useful in other flows based on JSON Schemas.
It can then easily be plugged in to generate JSON Schema from OpenAPI/Swagger or AsyncAPI inputs + possibly even update outdated JSON Schema syntax into the latest and greatest spec version.
An additional benefit could be internally: That it would become possible to validate whether any data is lost in the conversions. Sending a JSON Schema as an input, generating a JSON Schema as an output and checking for substantial differences between the two. A good integration test?
Description
A new JSON Schema generator would have to be added.
This wouldn't be a breaking change.