mORMot Open Source

I have tested https://github.com/synopse/mORMot2/commit/e08e33ca3 with my current implementation.
I used GetCurrentUser, GetWorkItem, GetWorkItems, PatchWorkItem from the polarionrest.json of the first topic.
At least two commands had the issues mentioned before and are working with e08e33ca3. Great ! I used default settings  (i.e. none of the optDto*Reduce*).

Just out of curiosity, why are you doing

  TPolarionDto1573 = TPolarionDto197;

  TPolarionDto1570 = packed record
    _Type: TPolarionPolarionEnum54;
    Attributes: TPolarionDto1571;
    Relationships: TPolarionDto1573;  //could use TPolarionDto197 directly here?
  end;

If the answer is "the dedup alogrithm is easier", does the compiler reduce this automagically ?

I tried with https://github.com/synopse/mORMot2/commit/fe1370e77
it complies and except for the case mentioned before it seems to work.

one cannot answer the question if the code snippet is correct as one would need to see the content of TDtoApi2764

I draw a small and simplified uml which hopefully shows that the issue becomes apparent one step below the Data record.

https://github.com/D-H-R/various/blob/m … sponse.png

As I'm not sure if the numbers stay constant I also added the generated files: https://github.com/D-H-R/various/tree/m … _generator

@ab: thanks for pointing that out. I Did not double check AI output enough, which set it on the wrong line. Shame on me, thanks to you

Should the DtoTypePrefix get a CLI parameter for the mopenapi tool or is it already and did I miss it too?

Thanks for having a look into it. As it is a "side project" I need some days time until I can have a look back into it

I'm not 100% sure. But I think there is an issue. I wrote a small sample application that Gets and Puts a "Trackeritem". With the original mormot 2.4 release its working.
With the commit mentioned i added oa.DtoTypePrefix:='CodeBeamer'; to mopenapi tool.
generated Files look good.

I just exchanged the generated Files and added the "CodeBeamer" Prefix to the types, after that, the
GET REST command is working but for PUT command I now get: {"message": "JSON parse error: Class cannot be resolved by type: ","resourceUri":"/items3956"} during the runtime when I call the generated put function.
I know this looks like a "user issue" not using the REST Api correct, but as I did not really change s.th. in the code and it worked before...

Please let me know when it makes no sense to talk about it wihtout the actual source code. I'll check whats possible then. I dont know if they allow me to put the openapi spec public, as i needed to login to get it.

Thanks so much.

Ok variant works, but ... its a variant
i.e. string:=variant works at compile time, but obviously crashes at runtime. Since I like strong typing, I'd prefer to get a compiler error.

Question: Can I have something that is like a dynarray but serializes as human readable correct json instead of blob?
(Note: TStrings gets JSON : "StrArr": "[\"1\",\"2\"]", but I need "StrArr": "["1","2"]")

I have not yet all my use cases covered but the question how to access "note" from the inner ojbect is solved:
I used IDocList / Dict and it works like a breeze

dict := DocDict('{"text":"Some general Annot. Description","measurementData":[{"id":47,"note":"erster Teil","values":[1.1,1.2,1.3]},{"id":11,"note":"zweiter Teil","values":[2.1,2.2,2.3]}]}');
Memo2.lines.add('oneliner note' + dict.GetL('measurementData').GetD(1).GetS('note')); 

Thank you for you answer,

I'm lost in some rabbit hole Every hour I'm working with it I'm more confused.
I'm using Lazarus 4.2 FPC 3.2.2

At least for now I put everything into records, and used TArray instead of IList. My best guess so far is documented at https://github.com/D-H-R/mormot_json/bl … /unit1.pas.
I know that RecordSaveJson is supposed to do base64 encoding, I wasn't able to get s.th. else running

As you might have expected I need a human readable format.

Can you please point out to me which classes (for data holding) and functions for the "toJson" I should use for a first approach.

Thank you so much.