You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2017-11-25 19:02:41
- wloochacz
- Member
- Registered: 2015-01-03
- Posts: 45
Bug on SAO serialization with object...
Hello!
DTO Class
type
TdtoPpTool = class(TdtoBaseClass)
strict private
FIdTool : RawUTF8;
FToolCode : RawUTF8;
FToolConfDescription: RawUTF8;
FToolName : RawUTF8;
published
property IdTool : RawUTF8 read FIdTool write FIdTool;
property ToolCode : RawUTF8 read FToolCode write FToolCode;
property ToolName : RawUTF8 read FToolName write FToolName;
end;
TdtoPpToolArray = array of TdtoPpTool;Intf
IdrsPpTask = interface(IInvokable)
['{82314755-AD47-4E0D-BBE8-322664E9061A}']
function GetTool(out ACTR : TdtoPpTool) : TrsAnswer;
end;Class:
function TdrsPpTask.GetCtr(out ACTR: TdtoPpTool): TrsAnswer;
begin
ACTR := TdtoPpTool.Create;
ACTR.IdTool := 'id';
ACTR.ToolCode := 'code';
Result.Reset(rsaOK);
end;Server response:
20171125 18432413 ret mORMot.TSQLRestServerFullMemory(0C60AE80) {"result":[{IdTool:"fiuck",ToolCode:"code",ToolName:""},{"Status":0,"Msg":""}],"id":12632}Server response, please take a look:
{
IdTool:"id",
ToolCode:"code",
ToolName:""
}This is not a VALID JSON.
JSON does not contain quotes for property names. Of course, the client is AV during Json To Object... (Dlaczego nie ma wyjątku - Invalid returned JSON content)
Interestingly, if the out parameter is an array type (TdtoPpToolArray = array of TdtoPpTool;), then all is OK.
Please AB, fix it.
Or tell mi how to fix this 
PS.
Looks like a similar problem to (dzięki Jacek, masz flachę ;-)):
https://synopse.info/forum/viewtopic.php?id=3763
Offline
#2 2017-11-25 21:09:15
Re: Bug on SAO serialization with object...
Between Delphi clients, it will use the "extended" JSON syntax, as documented.
With a real REST client - if and only if there is an UserAgent defined in the HTTP headers - slower standard JSON will be emitted.
Online
#3 2017-11-25 21:09:53
Re: Bug on SAO serialization with object...
It is not a bug. This is not what you expect, but this is what is expected by the framework.
Between Delphi clients, it will use the "extended" JSON syntax, as documented.
And there will be no A/V nor any problem.
With a real REST client - if and only if there is an UserAgent defined in the HTTP headers - slower standard JSON will be emitted.
Online
#4 2017-11-26 11:10:05
- jaclas
- Member
- Registered: 2014-09-12
- Posts: 215
Re: Bug on SAO serialization with object...
But AV is raised on delphi/mORMot client side when mORMot parser try parse this JSON.
Offline
#5 2017-11-26 11:43:15
- wloochacz
- Member
- Registered: 2015-01-03
- Posts: 45
Re: Bug on SAO serialization with object...
OK, I'm going to prepare a test, because we probably did not understand ...
As jacll writes, AV is on the client side of Delphi program.
Offline
#6 2017-11-26 11:46:26
- wloochacz
- Member
- Registered: 2015-01-03
- Posts: 45
Re: Bug on SAO serialization with object...
Between Delphi clients, it will use the "extended" JSON syntax, as documented.
With a real REST client - if and only if there is an UserAgent defined in the HTTP headers - slower standard JSON will be emitted.
OK, how to control it?
How to setup server to any client (Delphi program or real REST Client), get the same JSON content?
Offline
#7 2017-11-26 13:30:54
- wloochacz
- Member
- Registered: 2015-01-03
- Posts: 45
Re: Bug on SAO serialization with object...
Sample application:
1. Get array of TdtoPpTool (TdtoPpToolArray)
Everything is OK.
2. Get TdtoPpTool = AV on Delphi Client.
So, really it is not a bug? ;-)
SourceCode based on sample 14 (Project14ServerHttp):
http://www.dflex.pl/dflex-ftp/mORMot/mO … roblem.zip
Offline
#9 2017-11-27 10:37:52
- jaclas
- Member
- Registered: 2014-09-12
- Posts: 215
Re: Bug on SAO serialization with object...
Ok, mistake is in wloochacz code, but imho raising AV makes it difficult to find the error. Can this exception talk about the actual reason?
Offline
#10 2017-11-27 10:38:00
- wloochacz
- Member
- Registered: 2015-01-03
- Posts: 45
Re: Bug on SAO serialization with object...
In fact, you are right and I thank you very much for your time.
Sorry for confusion, too much code, too little sleep: /
However, I lost a lot of time, because the exception that mORMot reports is far from the cause of the problem ...
Can we do anything about it in this case?
PS.
In my opinion, if a method returns an object by out, it should create it by the default constructor. Always.
The mORMot is exactly the opposite.
Of course, if you have adopted this convention then there is nothing left to do with it.
Offline
#11 2017-11-27 10:57:14
Re: Bug on SAO serialization with object...
It is to ease the server side code: the instance is there...
But on the client side, you have to handle it.
It is my bias: I am more a server-side guy, for sure!
The real reason is that it will ensure that the instance lifetime is handled by the caller on the interface method.
It may be very easy to return an existing instance, then it will be released by the server SOA caller, and it will trigger unexpected A/V randomly - very difficult to track - on the server side. Which is what we want to avoid...
Whereas a pointer to nil gives always a clear access violation on the client side, which doesn't affect the server.
So it was designed as such to make the server side more resilient to errors, even if the client side is a bit more complex to work with.
Usually, on the client side, you can safely pre-allocate your object instances, and reuse them.
Online
#12 2017-11-27 11:16:50
Re: Bug on SAO serialization with object...
Note that it was clearly documented as such:
The caller shall instantiate an instance before call - whereas for "normal" Delphi code, it may be up to the method to instantiate the instance, and return it.
I've enhanced the documentation to explain the reasons more precisely.
See https://synopse.info/fossil/info/0aafb94582
Online
Pages: 1