#1 Re: Low level and performance » Recommendation for string conversion issues » 2020-01-14 19:06:46


Thanks for the opinion.

And to write new SynCommons-dependent utility units as you usually do?

Uses RawUTF8 in all parameters?

#3 Low level and performance » Recommendation for string conversion issues » 2020-01-13 18:41:25

Replies: 4


I am converting some of my (old) code to use DocVariant as a JSON implementation.

But by including SynCommons in uses the compiler generated several explicit conversion warnings from / to string.
Due to SynCommons reintroducing various methods like  Trim, etc. that uses RawUTF8.

function OneFunction (AString : String) : String;
    Result := Trim(AString);  //This generate a warning since SynCommons.Trim expects RawUTF8

I would not want to change everything to RawUTF8.

Some options I think:

- Leave SynCommons as the first uses unit. So that SysUtils, etc. override these functions.

- Use RawByteString as parameters.

- Explicit name of a unit: SysUtils.Trim (...)

What would be the suggestion to better resolve these conflicts? Along with maintaining the best performance possible?

NOTE: This code is being compiled in Delphi 10.3 / FPC. I do not need Unicode compatibility with previous versions of Delphi.

#4 Re: mORMot 1 » Publishing a RESTFul server » 2019-05-03 20:04:16


Thanks Arnaud, for the clarifications.

I think I understood all the points, and method-based really seems to be the best option.

Since the method name will be part of the uri, if I create a "apiv1" method, this one method will automatically receive all requests related to TSQRecord's registered.

So in the method I use Ctxt.Table and Ctxt.TableID to process as I need.


#5 mORMot 1 » Publishing a RESTFul server » 2019-05-02 21:51:32

Replies: 2

Hello friends

First of all congratulations for the work, I'm delighted with the possibilities.

I am studying the framework and developing a test project to run a RESTful server.

Well, going to the point, I have these two doubts that I could not solve via documentation or research in the forum. Sorry if it was already answered.


1 . Is it possible to change the default behavior of the REST server published by ORM?

For example, when accessing /root/product all the ids of the Products table are listed.

I need only list the searched records, for example:
/root/product?category= 4

And that list the complete product data and not just the ID.


2. Is it possible to remove attributes from the returned JSON, to hide sensitive data such as passwords?

Example: /root/user/1 returns

"ID": 1,
"Name": "Jhon",
"Password": "xyz": <- I Need to omit this property

Since RegisterCustomSerializerFieldNames and RegisterCustomSerializer... dont work with TSQLRecord classes, How could this be done?


If this is not possible the only alternative would be through method-based services, since interface based services dont handle PUT, DELETE... verbs, correct?

In this case will I need to mimic all methods of ORM's REST implementation? Or I can change just what I need.


GET /root/product/1 -> Handled by default ORM Rest ...

GET /root/product -> Handled by method-based service to list complete product data, search, pagination, etc.

GET /root/user/1 -> Handled by method-based service to hide properties, etc.

POST /root/user -> Handled by default ORM Rest ...

Best Regards


Board footer

Powered by FluxBB