mORMot Open Source

I used SynCommons.HexToChar in my custom SynCommons.TTextWriter as a part of XML unescape add-method.

Also THTMLEncoding.DoDecode might help: http://docwiki.embarcadero.com/Librarie … MLEncoding (haven't tried it myself though)

I'm using the trunk Zeos version. You could try it, probably not all fixes go to patches for a stable Zeos.

https://sourceforge.net/p/zeoslib/code- … ree/trunk/ or https://github.com/frones/ZeosLib

I assume there shouldn't be any problem in reading from WIN1250 FB DB. TDocVariant from RowDocVariant should contain a full RawUTF8 string. Could it be that you got the loss afterward? maybe due to direct string assigning

Yep, exactly. I was trying to express myself with words, but it seems your example explains everything better

You can use TSQLRestServerDB instance directly from TSQLRestServerFullMemory services/methods implementations.
I'm also using such an approach, works perfectly and no need to worry about DB access since it is internal.

Nice!

I'm getting the exception about outdated static lib on Delphi 10.4.1 Win64. Is it missing or my build is broken?

(had to pause my migration to 2.0 and return to 1.18 for a while - need to do some work)

Nope, checked it with step over - seems it passes the whole mormot.core.log.InitializeUnit well. Exception appears at mormot.core.json.InitializeUnit.

Delphi 10.4.1 Win64

I was curious why not all projects are failing and I think I found something, hope useful. At least, now I can overcome the exception.
This particular project contained mormot.core.log in uses list in dpr (I was setting LOG_VERBOSE sometimes directly in dpr for having a full log).
Such order causes an exception with the latest commit:

program NextGeoViewSQLite3mORMotDemo;
uses
  Vcl.Forms,
  mormot.core.log,          <--------- before the main form unit
  mormot.core.rtti,
  uFormNextGeoViewSqlite3MormotDemo in 'uFormNextGeoViewSqlite3MormotDemo.pas' {FormNextGeoViewSqlite3MormotDemo},
  uNextGeo in '..\..\Source\uNextGeo.pas',
  ...

And this order goes well, no exception:

program NextGeoViewSQLite3mORMotDemo;
uses
  Vcl.Forms,
  mormot.core.rtti,
  uFormNextGeoViewSqlite3MormotDemo in 'uFormNextGeoViewSqlite3MormotDemo.pas' {FormNextGeoViewSqlite3MormotDemo},
  mormot.core.log,          <--------- after the main form unit
  uNextGeo in '..\..\Source\uNextGeo.pas',
  ...

I'm not sure so far what has happened, some (not all) projects stopped working with the latest commit. Such exception appears at the start:

Project NextGeoLoadDemo.exe raised exception class EJSONException with message 'Rtti.Count=5 at mormot.core.json start'.

All works fine with the previous commit, the problem seems to appear with 544078bdf080cd6a80566461567cbc84131a948f only.
Could it be that I'm using logs incorrectly since the last commit concerns only mormot.core.log unit?

Will definitely study it, thanks! And look into your implementation.
I've learned so much from the mORMot. Although, sometimes it is really hard for me to understand some code from the first, second, or even tenth look

I would not say that I ever regretted about mORMot memory consumption, but that sounds Very nice! Even if so far I don't understand the particular advantage of it, I already always know for sure: if Arnaud made something new, it will be better, more optimized, faster, and so on

I guess I can share some results of the first stage of my migration to mORMot2. I Hope, it'll be interesting for somebody.

I have done the migration of only one small project group (6 Delphi projects) and a part of my base classes, using mORMot. It contains several TWinHttp-based REST/JSON clients for different web-services with automatic DTO handling. It also contains some work with external DBs: FB2.5 and SQLite3 (ORM, batches, etc.). It doesn't contain any server/daemon. Custom serialization is frequently used there. Some projects are using threads. And it all works well with mORMot2, now
At first, I made it working in compatible with 1.18 mode, then I switched to PUREMORMOT2 - it was a good opportunity to review, clean, and refactor the old code.
I use my own base classes, based on mORMot classes - probably it made the whole process a bit easier for me.

My personal impressions:
- from the beginning, it was pretty hard to find needed classes and functions, but after several days I became pretty used to it.
- I missed some documentation for mORMot2 like for 1.18 - Arnaud spoiled us The documentation often helped me to understand different ways and choose the best one.
- the framework source code formatting became more readable (just for me, at least).
- naming also became much more convenient (for my taste - "Kotlin-way" and UTF8String are very nice).

My current losses:
- Zeos support (temporary).
- EngineAdd, EngineUpdate, EngineBatchSend overriding for TRestServerDB, which I used for universal transliteration (our legacy FB DB is using ISO8859_1 ) - will try to find another workaround for it. Can't afford this loss.
- i18n, I couldn't find some functions, which I used before. But it is probably will be not needed at all, so I have cut it off.

It took pretty much time to get used to mORMot2, but I consider the first stage of migration to be successful I'll continue the process with other much more complex project groups.

My current personal situation:
- my employer sticks Delphi (a huge old legacy product),
- the client of my employer uses Windows infrastructure.
In addition, I have much less experience with Unix it just happened so.
And I would admit that with all Windows disadvantages (and prices) it is always easier to start/work with it, especially if you have some lack of knowledge/experience.

It would be a piece of nice and useful information I guess, at some point, everybody gets the need to have some cheap and stable standalone server (at least, for testing). And this information can make the choice easier.
Currently, I'm not using any, but I assume I may need one someday in the future.

I used ultravds.com for years: adjustable, fast, no direct limits, cheap. I had no single problem with it.
In my case, it was even cheaper -40%: 20% for yearly payment and 20% for the rare promo code, which one guy gave to me on some forum many years ago (checked it, still works, btw, if somebody needs it).
But! it is located in Russia. So, think twice. Probably, it is just a corrupted opinion of the man, living in Russia, but I would not use it for something important or sensitive.

yeah, I had no doubts that it is just a "technical" issue. Decided to notify just in case

Also had this warning, but then downloaded static files from another link: https://github.com/synopse/mORMot2/rele … 2static.7z

Ah, I see. Tested the new version, all works, nice! Thanks for the fix and the explanation!

Ok, probably this decision is ugly, but at least it works for my case.

Instead of (1.18)

              TSQLRestStorageExternal(StaticVirtualTable[LModel.Tables[i]]).OnEngineAddComputeID :=
                DoOnEngineAddComputeIDFirebird;

for 2.0 I used

          TRestStorageExternal(TRestOrmServer(server).StaticVirtualTable[LModel.Tables[i]]).OnEngineAddComputeID :=
            DoOnEngineAddComputeIDFirebird;

Overriding EngineAdd, EngineUpdate, EngineBatchSend for the whole TRestServerDB-based class, unfortunately, seems to be impossible, so far at least.

Joining all kind words!
I will try to test migration starting from some simple projects. Will mORMot2 stay located at the same repository https://github.com/synopse/mORMot2?

Sorry, I'm not sure about ServiceResultStart/End since I haven't used them. I took a quick look at these methods, I am afraid it might be not enough. Hope, Arnaud or other guys will advise you something better.

We're using custom ServicesRouting and TServiceCustomAnswer in services for a heavy project (FHIR-specified), where we had to override almost everything to make it automatic and compatible with third-party software: fhir+json/fhir+xml output/input data formats, different http-methods, custom meaningful headers, and much other stuff...

I guess this code might be slightly better since it will get the pointer just one time:

  with _Safe(vJSON.id)^ do
    for intX := 1 to 10 do
      AddItem(intX);

or local variable can be also an option.
Anyway, these are just details, of course.

Yeah, sorry, you're right. I took a look at _Json function. Quotes are not necessary:

// - in addition to the JSON RFC specification strict mode, this method will
// handle some BSON-like extensions, e.g. unquoted field names:

I made a test. In my case (D10.4.1) your code works without any error in both cases.

upd: tested it with 10.3.3 and 10.2.3 also - all goes fine

Glad to hear that

Yes, I also came to these two paths. I haven't found the best approach yet (that's why I was particularly interested in this thread), but for the temporary solution, I decided to parse coordinates on-demand ("alternative way", as you described). The reason is that I have to work with rather big .geojson files (up to 400 Mb) and I do not need all GeoJSON objects coordinates at once. I do not need serialization in GeoJSON format, so it also makes it a bit easier.

One more thing, which might simplify type-handling. I assume you may know this already, so it is just in case. Using enumerations, like this:

  TGeoJsonType = (gjtUnknown, gjtPoint, gjtMultiPoint, gjtLineString, gjtMultiLineString, gjtPolygon, gjtMultiPolygon,
    gjtGeometryCollection, gjtFeature, gjtFeatureCollection, gjtName, gjtLink);

And, for example:

  TGeometry = packed record
    coordinates: RawJSON;
    &type: TGeoJsonType;
  public
    function GetLineString(out AResult: TPoint2DList): Boolean;
    function GetMultiPolygon(out AResult: TMultiPolygon): Boolean;
    ....
  end;

This option will trim all textual enumerations "gjtLineString" -> "LineString":

TJSONSerializer.SetDefaultEnumTrim(True);

Enumerations will allow to simplify (and speedup) types checking: &type=gjtLineString instead of &type='LineString'. And "case &type of ..." might also make things easier in some cases.

Noted for the future, thanks!

Agree, it left there from another earlier try. needed_for_rtti can be easily removed.

Yeah, also thought so, but somehow it didn't work for me. Maybe I have mistaken somewhere. But it doesn't make much difference as far as I understand. At least custom reader/writer will be the same, I guess.

a dynamic array of records? wouldn't "lng"/"lat" names appear then in output?

I meant that Delphi reserved word "type" can be declared as "&type" property in the record

TGeometry = packed record
        coordinates: ...;
	&type: RawUTF8;
end;

I was just trying to say that reserved word shouldn't be a problem. Probably I just misunderstood something about it, don't mind.

Anyway, it seems that @robs is working with GeoJSON. I was interested in that because I'm working with it on my actual project.