OpenAPI Multiline description comment bug about mormot2 HOT 8 CLOSED

This is a work in progress.
Please try again later.

One note: there is no \n nor any set/enum in the supplied .json file.

from mormot2.

This is a work in progress. Please try again later.

One note: there is no \n nor any set/enum in the supplied .json file.

That's in the "description" string object some of it contains \n and \n\n

And as for the set It's generated in the .dto.pas file from the JSON file I attached.

from mormot2.

Please try with the current version.

But I still don't understand what means:

the names of the Sets are very long.

I suspect the .json you provided is not the one you use.
There is no enum/set in them.
Nor any notion of "Sandbox" in the descriptions.
If the sets have no name in the .json then a name is computed from the description text, which may indeed be quite long.

from mormot2.

Please try with the current version.

But I still don't understand what means:

the names of the Sets are very long.

I suspect the .json you provided is not the one you use. There is no enum/set in them. Nor any notion of "Sandbox" in the descriptions. If the sets have no name in the .json then a name is computed from the description text, which may indeed be quite long.

The bug for the new line comments is fixed now.
The file is the same, and I think the OpenAPI: truncate too long generated identifiers already fixed that.

Another thing about the RegusterRtti that it complains about _TProtobufAny = '@type:RawUtf8';

I don't know how the RegisterCustomEnumValues works, but it didn't like the @

from mormot2.

Where does this '@' comes from?

It should not exist within our PascalName content.

Please provide a .json to reproduce the issue.
Your previous link has no trouble.

Also ensure you use the very last version of the unit from tonight: I just committed a lot of fixes.

And one last tip: ensure you specify a aTypeSuffix prefix to TOpenApiParser.Create() otherwise the enumeration and type definitions names may overlap, and the RTTI is lost: this may be the culprit of your "definition covers % bytes" exception.

from mormot2.

Where does this '@' comes from?

It should not exist within our PascalName content.

Please provide a .json to reproduce the issue. Your previous link has no trouble.

Also ensure you use the very last version of the unit from tonight: I just committed a lot of fixes.

And one last tip: ensure you specify a aTypeSuffix prefix to TOpenApiParser.Create() otherwise the enumeration and type definitions names may overlap, and the RTTI is lost: this may be the culprit of your "definition covers % bytes" exception.

I do use a prefix, Here's the code I'm using

program mORMot2_RnD;
uses
  mormot.core.fpcx64mm,
  mormot.core.base,
  mormot.net.openapi{, Nakama.dto, Nakama.client};

var
  Nakama : TOpenApiParser;
begin
  Nakama := TOpenApiParser.Create('_NK_');
  try
    Nakama.ParseFile('E:\GameDev\NakamaProject\nakama\apigrpc\apigrpc.swagger.json');
    Nakama.ExportToDirectory('Nakama');
  finally
    FreeAndNilSafe(Nakama);
  end;
  WriteLn('Done');
  ReadLn;
end.

It is the same file

Please Check the protobufAny object in the file.

    "protobufAny": {
      "type": "object",
      "properties": {
        "@type": {
          "type": "string"
        }
      },
      "additionalProperties": {}
    }

In its properties, you will see @type, which is used in the string used in the RTTI registration.

And you would see that It's handled in the generated code but not in the string _TProtobufAny = '@type:RawUtf8';

  // from #/definitions/protobufAny
  TProtobufAny = packed record
    _Type: RawUtf8;
  end;  

This problem happens when you put the generated files in the uses and try to run the app.

from mormot2.

Now I understand.

Please try with the latest commit: it should be fixed now.

from mormot2.

nakama.zip
Here are the generated files.
They seem correct to me.

from mormot2.