mORMot Open Source

I would recommend taking a look at SynCrtSock unit, there are several client classes. I'm using mostly TWinHTTP-based classes for many third-party REST services with different rather complex schemas. But probably the fastest and easiest way might be TSimpleHttpClient.
JSON parsing to object: https://synopse.info/files/html/api-1.1 … ONTOOBJECT

I like this suggestion, it seems clearer for understanding for mORMot-newbies from my pov. Although I'm not sure if it will be ok for compatibility (with other libraries including), I would not call myself proficient in this question.

For me it is completely different - I like this way of abbreviating use in naming Maybe it is a matter of taste (I'm just sharing mine), but when I get occasionally the situation with several abbreviations in one name - it is very hard for me to use uppercase only. Something like TJWTRS256 or TUTF8XMLCDATA or whatever else - there are so many abbreviations today. So TSqlRecord (or Orm) seems for me much more convenient than TSQLRecord (or ORM).

JOSE JWT lib can be also used with TJWTAbstract subclass as an alternative: https://github.com/paolo-rossi/delphi-jose-jwt

If I understood it correctly, I guess, you can try smth like (not tested)

LBatch := TSQLRestBatch.Create(YourRestDB, nil, 1000);
LRecord := TSQLYourRecordClass.Create;
LRecord.FieldToUpdate := NewValue;
for i := 0 to IDsCount - 1 do
begin
LRecord.IDValue := IDs[i];
LBatch.Update(LRecord, 'FieldToUpdate');
end;
FreeAndNil(LRecord);
YourRestDB.BatchSend(LBatch);
FreeAndNil(LBatch);

But if it is possible, I would use a direct sql statement for such case, although sometimes it is not the best decision of course.

I would not be so strict about packages and mORMot 'Classic' ways of using mORMot - probably, but imho it all depends on particular desires.
Sometimes I have to rewrite some parts of mORMot for complex projects. Just the last week we had to create our own TSynAutoCreateFields for supporting generic lists (VMT Autotable cache is a brilliant idea, btw thanks Arnaud!). And in the same project we have many other things rebuilt but based on similar technics and mORMot base classes and functions.
If we would imagine that someday I'll want to put those base mORMot only used stuff in packages, and ours in others - why would it be a bad idea? I'm asking not because I'm trying to prove smth - I really would like to understand the danger.

Nice, it is always useful to have such an option to switch to packages

Sorry, I'm not proficient in Asp.net, can't help much. I would check the client for JWT/OAuth support, some clients might have automatic abilities for token renewal.
So far, in basic, I see only two ways of handling JWT expiration:
1. JWT Issuer/User (your client here) checks the JWT expiration time before request and renews it if needed (generates a new one or requests a new one in case of standalone auth-service).
2. Like @macfly suggested, renewal can happen in case of a token-expiration response from the server. But you'll have to know the error-response structure then, parse/analyze it, and have an ability to retry the same request with another auth-JWT header after renewal.
I prefer the first way - it seems for me faster and clearer.
Probably, somebody else here can suggest another way or/and help you with asp.net client implementation.

Yes, but wouldn't it be slightly slower?

And one more question concerning the client-side, if you don't mind.
I had to use TSQLHttpClient.OnEncryptBody event for forming custom headers (incl. bearer JWT) and URL parameters for Every request, but the meaning of OnEncryptBody is a bit another as far as I understand. Is there any better way to do that?

using Zeos trunk 6758, now - no problem with FB 2.5.9 (+ USE_SYNCOMMONS)

Sorry for the misleading information. We've found in code that there was tmMainConnection ThreadingMode set.
We need to check it more, but so far with tmThreadPool all seems to work fine. My bad

Great, thanks

Probably we got one problem with the new IsObjectDefaultOrVoid function.
We have several temporary fields (type variant), which are rather complex by the standard - we'll deal with them a bit later.
Anyway, if this variant field was not assigned, I get an AV in ObjectToJSON with woDontStore0:

Project NextFhirParserDemo.exe raised exception class $C0000005 with message 'c0000005 ACCESS_VIOLATION'.

AV raises at TPropInfo.IsDefaultOrVoid function:

...
  tkVariant: begin
    p := GetFieldAddr(Instance);
    result := (p<>nil) and VarDataIsEmptyOrNull(p^);             <------ here
  end;
...

Am I missing something? Maybe we shouldn't use a variant type for temporarily handling some complex substructures.

Yes, you're right. I'd like to minimize custom serializers (we'll have enough of them in that huge structure of all resources). Besides this avoiding empty objects in resulting JSON will be applied to all resource objects, so a universal decision seems to me preferable.

I followed your suggestion with OnWriteObject event. The only correction (I understand that it was just a typo in your message): to avoid standard object processing it should return True result.
Anyway, it worked!

I decided to make some speed comparison tests, here are the results on my PC for the same object: https://pastebin.com/zfm5CxRR
Of course, it all highly depends on the object and class and current PC state (time values are very small), still, OnWriteObject implementation works several times faster than JsonRemoveVoidObjectsAndArrays!
Thank you very much!

Probably I misunderstand something, but why not use TKonfiguracja directly as a parameter in your service method? I think it will be transmitted as JSON object without any additional action.

As far as I understood, you have already the needed value in Dokument.data_wystawienia. Then, I guess, if you have Dokument.IDValue set correctly, you can simply do:

ServerDB.Update(Dokument, 'data_wystawienia');

But even with your code, I think, it could work if you used DateToSQL/DateTimeToSQL functions, like:

ServerDB.UpdateField(TDokumentClass(TDokument),TID(ID),'data_wystawienia',DateTimeToSQL(Dokument.data_wystawienia));

Yes, it's working again, thanks for a quick fix!

Yes, all is good, now. Thank you!

Hi Michael! Yes, with [r6577] almost all works fine. Thank you!

Could you only make a couple of additional tiny fixes (or it won't compile):

ZDbcMySqlResultSet.pas, line 508. Missing closing bracket. Fixed line:

JSONWriter.AddNoJSONEscape(PUTF8Char(FByteBuffer),9+(4*Ord(jcoMilliseconds in JSONComposeOptions)));

ZDbcOracleResultSet.pas, line 500. Excess closing bracket. Fixed line:

JSONWriter.AddNoJSONEscape(PUTF8Char(fByteBuffer),9);

well, I continued the investigation, and when I got to SynDBZeos.TSQLDBZEOSStatement.ColumnsToJSON procedure, I noticed there

  {$if defined(ZEOS73UP) and defined(USE_SYNCOMMONS)}
  fResultSet.ColumnsToJSON(WR,fJSONComposeOptions);
  {$else}
  ...

And since I have USE_SYNCOMMONS definition in all mORMot+Zeos projects according to @EgonHugeist recommendation, this code is running.
I tried to rebuild the project without USE_SYNCOMMONS, and all worked as intended.
That's why I couldn't find the particular change in mORMot and Zeos repos
So, I guess, the problem is somewhere in fResultSet.ColumnsToJSON, which launches with USE_SYNCOMMONS. Does it help somehow, or I should go deeper?

maybe it is not the best way, but if I need to edit json (in a quick-coded way), I usually use TDocVariant. Smth like this:

var
  LRecord: TMyRecord;
  LDocVar: TDocVariantData;
begin
  LRecord.id := '1';
  LRecord.name := '22';
  LRecord.last_name := '333';
  LDocVar.InitFromTypeInfo(LRecord, TypeInfo(TMyRecord), False, []);
  LDocVar.Delete('id');
  Memo1.Text := UTF8ToString(LDocVar.ToJSON);
  ...

{"name":"22","last_name":"333"}

btw, the record is better to be packed, I guess:

a bit embarrassing but I have to tell that I was avoiding TDocVariant almost always. Just rarely used it for fast getting some value from some JSON.
And now I tried it with several different structures and I must admit that it is useful and rather simple! Of course, so far I'm not sure that I'm using it the best way, but I will get it after some more experience.
I will use it in many places of my projects, thank you for your hints, guys! and sorry, @edwinsn, for a kind of offtopic

About a week ago expected the same JSON format of TRawUTF8DynArray field value, but unfortunately didn't get such a result Therefore I had to make a quick workaround with the calculated field.

I wonder, why some people here are so obsessed about giving up Delphi 7 support?
I'm using 10.3 and I have no problem with Delphi 7 support in mORMot. Arnaud asked everybody about versions, which they need to be supported in 2.0. He made a decision according to the results of the survey. Does he make you doing something to make it happen? Then what does bother you so much?

While choosing words like 'bullshit', please, don't forget that in the context you're talking about somebody's job, life business, or hobby.

Strictly saying, this particular service is not for users. It loads (and updates) a huge amount of data from different national services. Most of these services provide UTF8 data. And some of this data (names, mostly) sometimes contains non-ISO8859_1 characters. So, anyway, I have to make a transliteration before posting it to DB. The reason why I'm not doing that: I tested Zeos codepage setting and it worked as needed automatically.

I made a separate test to find how it works (as I did earlier, much time ago). Here is the result:
'ČOAVVÁ ÁDO' name received from the person registry as UTF8. It contains Č, which is not a part of ISO8859_1 encoding. Then mORMot->Zeos->FB and in DB (with ISO8859_1) we have 'COAVVÁ ÁDO', which seems rather good for use in another software, where users work. No question marks or another significant loss.
I do not consider myself as anyhow expert in encodings and stuff. So, any correction from your side is very welcome.

I understand, that it is slower than with UTF8 only. Probably it is not the best design with such a restriction of using ISO8859_1 FB DB. I'd appreciate any hint for better design, but without converting DB to UTF8. We can't do that, so far at least.

Sorry, this part I couldn't understand even after reading it several times. Could you explain it to me a bit more, please? Why it should be cyrillic encoded? Maybe I'm wrong, but I think that ISO8859_1 (or Latin-1) doesn't support cyrillic characters, and it doesn't make sense in fact: NO_NO collation is for Norwegian language. I'm a bit confused here...