mORMot Open Source

Hi!

I've asked that before, but in mORMot1 - now, a few years on, I'd like to repeat that question :-D

--Daniel

In mormot.core.json we can pass the parameter var Valid: boolean, which is not set upon returning. It should be set as Valid := ctxt.Valid; at the end of the method.

Regards,
Daniel

When I use mormot.core.rtti and retrieve the properties of a class, each of them is represented by a "TRttiCustomProp" record. Is there a way to access the original Delphi rtti context information?

Reason: I want to check attributes assigned to that specific property. Another way to retrieve them would be appreciated as well ;-)

Regards,
Daniel

Good morning,

just pulled the latest changes, and found a little group of compiler hints.

[dcc32 Hint] mormot.net.async.pas(4727): H2077 Value assigned to 'forced' never used
[dcc32 Hint] mormot.net.async.pas(4730): H2077 Value assigned to 'forced' never used
[dcc32 Hint] mormot.net.async.pas(4733): H2077 Value assigned to 'ignored' never used
[dcc32 Hint] mormot.net.async.pas(4736): H2077 Value assigned to 'ignored' never used
[dcc32 Hint] mormot.net.async.pas(4724): H2077 Value assigned to 'ignored' never used
[dcc32 Hint] mormot.net.async.pas(4723): H2077 Value assigned to 'forced' never used

And the hints are correct ;-)

Regards,
Daniel

Hi arnaud,

I have created a pull request for RFC 9239 changes to e considered.

https://github.com/synopse/mORMot2/pull/242

Two changes according to RFC 9239

• "text/javascript" as mime content type for JS-files, "application/javascript" is defined as obsolete

• MJS-filetype to be handled like JS-filetype

https://datatracker.ietf.org/doc/html/rfc9239
https://www.rfc-editor.org/rfc/rfc9239

Regards,
Daniel

Hi,

in mormot.core.os is a method ObjArrayAdd with different params, than in mormot.core.base.
When both units are referenced, Delphi cannot find the correct version to call.
For example in mormot.core.unicode and mormot.core.rtti the compiler stops, only when prefixing them with mormot.core.base the compiler will find the correct one.
I am sure more instances would occur, when I look further.

Regards,
Daniel

PS: Current commit on github

Hi Arnaud,

it's been a while that I had a chance to update my local mORMot2 rep, as another project attacked my (not so) well laid out time table.

Anyway, one change, that grabbed my be surprise, is the use of records with methods, rather than the previous object approach. In mormot.core.json defines the TJsonSaveContext. In our project, I have created my own version of the (previously) object, and could, through a helper object, easily access the fields

    W: TJsonWriter;
    Options: TTextWriterWriteObjectOptions;
    Info: TRttiCustom;
    Prop: PRttiCustomProp;

to implement very specific sub cases. I do propose making those fields public, please :-)

Regards,
Daniel

Hi,

when using IRestOrm (mORMot2) and running into an error, it would be nice to get access to the error code returned by the sql engine.
Internally it runs TSqlRequest.Step and that raises an ESqlite3Exception, but the user of IRestOrm cannot get any details on the error occured.

Is there a way to access those information for possible internal handling of such situations.

Regards,
Daniel

Hi,

in Delphi, there is the possibility to declare arrays using TArray<...> rather than array of ..., which has a few advantages.

However, TRttiCustom.SetPropsFromText only handles array of ..., when parsing a string of properties.

When using code such as

  OrigRtti := Rtti.RegisterClass(aOrmClass);
  for var Prop in OrigRtti.Props.List do
      PropText := PropText + ';' + Prop.Name + ':' + Prop.Value.Name;

Prop.Value.Name will return TArray<...> when declared in that way.

Is there a fair chance of getting TRttiCustom.SetPropsFromText to work with TArray<...>, which from a mORMot pov would be the same, as array of ... ?

Regards,
Daniel