#1 Re: mORMot 1 » Error compiling in Lazarus/FPC » 2019-07-28 12:46:30


I don't know such page with detailed description of each FPC branch.

In general FPC "fixes3.2" seems like right choice for now. The stable 3.2 was not released yet and AFAIK the fixes3.2 is the base for incoming 3.2 stable release.

about Lazarus: Lazarus version has no meaning (it can be eventually more or less comfortable for end user including not working, but you should be able to use FPC from command line wink ). IMO always is worth to try new Lazarus for better UX.

#2 Re: mORMot 1 » Error compiling in Lazarus/FPC » 2019-07-26 11:39:09


You cannot expect from trunk any stability. Only "patches/fixes" branch and "stable" releases are stable.

#3 Re: mORMot 1 » Error compiling in Lazarus/FPC » 2019-07-26 11:27:48


No idea yet, this needs investigation. Probably some internal changes in RTTI layout (maybe even compiler bug). Try to use "fixes3.2" in fpcupdeluxe FPC Version instead of trunk.

#4 Re: mORMot 1 » Error compiling in Lazarus/FPC » 2019-07-26 07:19:38


Probably you should add to Synopse.inc the new directive:

{$modeswitch prefixedattributes-}

the problem is related to initial support of attributes in latest FPC trunk.

#5 Re: mORMot 1 » TSQLRestServer and SessionAccess » 2019-07-08 12:28:29


The first problem can be partially solved via custom TSQLRestServer.OnSessionCreate.

The second part can be solved via custom TAuthSession:

  TCustomAuthSession = class(TAuthSession)
    procedure ComputeProtectedValues; override;

procedure TCustomAuthSession.ComputeProtectedValues;
  fTimeOutShr10 := (QWord(User.GroupRights.SessionTimeout)*(1000))shr 10;
  fTimeOutTix := GetTickCount64 shr 10+fTimeOutShr10;

  MyServer.SessionClass := TCustomAuthSession;

Default precision is in approximation one second so all seems fine.

#6 mORMot 1 » TSQLRestServer and SessionAccess » 2019-07-08 09:41:58

Replies: 1


I found two problems with sessions.

The first:

when TSQLServer has single user and reOneSessionPerUser is used in TSQLAuthGroup.AllowRemoteExecute set, then the session is never released (deleted) even when session time out occurred.


the precision of timeout is too low for some automation processes (for example for bot clients). The minimal timeout can be set to one minute, IMO should be possible to set such timeout to second/few seconds in some cases. The behavior cannot be changed in simple way. The usefully would be virtual TSQLRestServer.SessionAccess (current SessionAccess cannot be overridden) or some other solution.

#7 Re: mORMot 1 » Smart Mobile Studio 3 - Compilation error » 2019-04-03 10:15:21


here is pull request (merged with latest mORMot) https://github.com/synopse/mORMot/pull/183 extracted from warleyalex archive.

Without improved examples - I have only SMS free compiler so examples  are not validated by me. I was able to compile some small project with latest SMS compiler.

Thanks warleyalex!

#9 Re: mORMot 1 » Database Error » 2018-11-13 21:50:47


AFAIK usage of ZEOS 7.3 is risky (in one of my bugreport (ZEOS bugtracker at sourceforge) some time ago I was warned that I should use 7.2). The recommended version is https://sourceforge.net/p/zeoslib/code- … .2-patches

Anyway whatever was said I was using selected 7.3 with important fixes for me ( PostgreSQL ). You can try to isolate minimal test case and use ZEOS bugtracker at sourceforge to report the problem.

#10 Re: mORMot 1 » Penentration testing / Pen testing » 2018-10-04 08:10:07


yes but "hacker/attacker" is able to logout user without user knowledge. AFAIK this is still actual : https://synopse.info/forum/viewtopic.php?id=2996

#11 Re: mORMot 1 » Penentration testing / Pen testing » 2018-10-03 16:06:44

ab wrote:

Note that Google or others do send plain passwords over HTTPS, so the mORMot handshake protocol is more secure for sure - at least you can never see the password, and can't replay an old signature! smile

the only what is possible is usage of current/latest signature to logout user ^^!

#12 Re: mORMot 1 » Penentration testing / Pen testing » 2018-09-14 10:34:07


Worth to note that OnBeforeBody behaves in different way for http.sys and socket server. For the http.sys OnBeforeBody is executed only when body exist but for sockets server OnBeforeBody is executed always (even when body is empty).

#13 Re: mORMot 1 » Record cannot be published under lazarus/FPC » 2018-05-18 08:14:17


We have plan to support this in NewPascal smile

#14 Re: mORMot 1 » NewPascal 1.9 cannot compile mORMot programs » 2018-05-08 10:38:00

edwinsn wrote:


What were you banned and can you point me to the page of the relative discussion?

to get full picture you need to track April/May mailing list archives (you can read all discussion by clicking "Next message (by thread)" in bottom):

http://lists.freepascal.org/pipermail/f … 38863.html
http://lists.freepascal.org/pipermail/f … 38880.html

after my last message I have got permanent ban smile - I have no access to SVN FPC repository/trunk nor internal "core mailing list".

TLTR, the general summary (this was not first situation):

http://lists.freepascal.org/pipermail/f … 38893.html

#15 Re: mORMot 1 » NewPascal 1.9 cannot compile mORMot programs » 2018-05-07 18:42:59


This was some time ago, when I was part of FPC core team and NewPascal was almost integrated with official FPC page... Now I have ban in FPC core mailing list and I don't have access to trunk anymore - there is no rational reason for my banishment... I am not able to provide any updates, bug fixes nor new features into FPC trunk. Political decision and revenge of one person in core team...

Anyway still nothing wrong with using FPC trunk instead of NewPascal - individual decision smile.

#16 Re: mORMot 1 » NewPascal 1.9 cannot compile mORMot programs » 2018-05-07 11:30:06


Both ways are good. Additional advantage of NewPascal is close cooperation with mORMot, so every change in critical parts of NewPascal (RTL, low level details) are handled in mORMot immediately. FPC trunk is also supported but in some situations update for mORMot may be delayed (and mix of FPC trunk and mORMot may be nonfunctional/full of bugs for some time).

Also NewPascal contains additional patches, bugfixes and features. For example "default field" feature or SmartPointers/ARC objects can be used only with NewPascal. I have also plan of special module dedicated for mORMot for extra features of NewPascal.

mORMot is freedom of choice smile

#17 Re: mORMot 1 » NewPascal 1.9 cannot compile mORMot programs » 2018-05-07 10:25:50


Probably you need latest Zeos (I am not sure here), you can download proper/newest version of Zeos here : https://github.com/newpascal-ccr/zeos

Zeos will be part of next release of NewPascal like mORMot smile .

#18 Re: mORMot 1 » NewPascal 1.9 cannot compile mORMot programs » 2018-05-07 07:26:26


If you decide to use option 1 then mORMot is ready to use as part of newpascal.zip archive (is located in ccr\mORMot directory) and is detected "out of box" in IDE (you even don't need to configure a project).
If you decide to use option 2 then you need additional step: you can download mORMot via fpcupdelux or you can do download on your own (for example from : https://github.com/synopse/mORMot )

#20 Re: mORMot 1 » Problem with TInterfacedCollection for Lazarus 1.8.2 » 2018-03-15 14:09:38


Did you try to use in modules :



#21 Re: mORMot 1 » ToTextPairs and InitCSV problem » 2018-03-15 10:55:34


Rather no. InitCSV don't decode, encoded string by ToTextPairs with twJSONEscape option (there is no way to use in proper way InitCSV when twJSONEscape was used in ToTextPairs).

#22 mORMot 1 » ToTextPairs and InitCSV problem » 2018-03-12 20:03:25

Replies: 2


seems that we have small problem. The data which is saved by :

SomeVar.test := 'test';
LIni := TDocVariantData(SomeVar).ToTextPairs;

and after is loaded:

WriteLn(SomeVar.test) // print "test"
LIni := TDocVariantData(SomeVar).ToTextPairs;
WriteLn(SomeVar.test) // print "\"test\""

works improper (the documentation says : the supplied content may have been generated by ToTextPairs() method). The SomeVar.test contains improper string (encoded JSON string).

The partial solution is:

LIni := TDocVariantData(SomeVar).ToTextPairs('=', #13#10, twNone);

but this is not the point. Probably some additional parameter for InitCSV is needed.

#23 Re: mORMot 1 » Is there a XPATH implementation? » 2018-02-19 10:26:13


the reality is not perfect and usage of JSON is not always possible. Personally I like the idea of :


some ideas from xml-js may be used in mORMot.

#24 Re: Free Pascal Compiler » Need help - SynZip fails on FPC(trunc) Win64 target » 2018-02-16 07:24:02

ab wrote:

This is a FPC zlib bug...

maybe is worth to report this on FPC mantis bug tracker?

#25 Re: mORMot 1 » TObjProxyVariant - new variant kind » 2018-01-31 22:03:40


Thanks, for improved/faster implementation. I think that TObjectVariant is better name smile. The description "lazy-loading to object properties from Variant" is perfect description of my intention.

#26 Re: mORMot 1 » TObjProxyVariant - new variant kind » 2018-01-31 14:15:46


TObjProxyVariant is here because ObjectToVariant not work for all cases. It is not art for the art but comes from practice and is widely used in my projects. Sometimes "pre generated" Variant form object is not best choice.

#27 Re: mORMot 1 » TObjProxyVariant - new variant kind » 2018-01-31 13:58:41


thanks wink TObjProxyVariant can be optimized a lot : by caching TSQLPropInfoRTTI and by TSynDictionary for fast lookup for property names. Anyway current implementation is fast enough for me.

#28 mORMot 1 » TObjProxyVariant - new variant kind » 2018-01-31 11:31:09

Replies: 10


I almost forgot about my new small feature already implemented some time ago : TObjProxyVariant


TObjProxyVariant is a custom variant type used to have direct access to object published properties. Very usable for cases where conversion from object to variant is not sufficient. TObjProxyVariant provides direct access to object properties from Variant instead of conversion to Variant. Example usage with mustache:


  mORMot, SynMustache;

  TA = class
    fi: integer;
    function GetR: Integer;
    property r: Integer read GetR;
    property i: integer read fi write fi;

  TB = class
    fa: TA;
    constructor Create;
    destructor Destroy; override;
    property a: TA read fa;

function TA.GetR: Integer;
  Result := Random(100);

constructor TB.Create;
  fa := TA.Create;

destructor TB.Destroy;

  b: TB;
  v: variant;
  b := TB.Create;

  TObjProxyVariant.New(v, b);
  v.a.i := 10;


example output :


#29 Re: mORMot 1 » Decrypt results differ for Win32 and Win64 (Delphi 10.2) » 2017-12-18 15:18:30


@ab seems that open array behave in different way than dynamic array

procedure TestMe(const Key: TArray<Byte>);

works as expected.

#30 Re: SyNode » Beta release of SyNode - ES6 JavaScript + NPM modules » 2017-11-08 12:14:03


@ab github release don't need to be related to stable release. I was thinking about github releases as of kind of storage for our all binaries. For example fpcupdelux has following "binary" releases not related (at all) to fpcupdelux source code:

Libraries for cross-compiling v1.1 : https://github.com/newpascal/fpcupdelux … slibs_v1.1
Darwin i386 binary toolchains for cross-compiling: https://github.com/newpascal/fpcupdelux … sbins_v1.0
GIT for Windows: https://github.com/newpascal/fpcupdelux … Git-2.13.2
GDB 7.11.1 for Windows: https://github.com/newpascal/fpcupdelux … gdb-7.11.1


we could do the same thing for mORMot for related libraries/object files

#31 Re: SyNode » Beta release of SyNode - ES6 JavaScript + NPM modules » 2017-11-08 08:58:01


IMO mORMot for github should use "releases" (like fpcupdeluxe and newpascal does - https://github.com/newpascal/fpcupdeluxe/tags, https://github.com/newpascal/newpascal/releases ). 

also is possible to use different categories for releases (by tags) for example sqlite_object_files, js_libraries.

Releases - very good way to keep all binary files around git repository:


#32 Re: mORMot 1 » SIGSEGV for TSynLocker and Pointers » 2017-11-07 08:33:42


I forgot to add Init/Done in example but SIGSEGV of course still occurs.

#33 mORMot 1 » SIGSEGV for TSynLocker and Pointers » 2017-11-04 22:20:12

Replies: 1


current implementation of TSynLocker is nonfunctional/buggy for pointers. Simple example will raise SIGSEGV


  Locker: TSynLocker;
  Locker.LockedPointer[0] := Pointer(1);

bug is very simple to fix:


I wonder why my pull request is still not accepted...

#34 Re: mORMot 1 » Error: TSQLDBSQLite3Statement.Step(SeekFirst=true) not implemented » 2017-09-08 20:00:46


What is strange - it works for few calls. I have error only for i = 2 or for i = 3 (it depends on TSQLRecord)... SQLite is used as external database because I need to use ISQLDBRows.

#35 mORMot 1 » Error: TSQLDBSQLite3Statement.Step(SeekFirst=true) not implemented » 2017-09-08 19:16:36

Replies: 4


maybe I miss something but for simple code like:

  FModel := TSQLModel.Create([TExampleData]);
  FServer := TSQLRestServerDB.Create(FModel, ':memory:');
  FProp := TSQLDBSQLite3ConnectionProperties.Create(FServer.DB);

  for I := 0 to 3 do
  with FProp.Execute('select count(*) from ExampleData', []) do
    if Step(true) then

I got error: "TSQLDBSQLite3Statement.Step(SeekFirst=true) not implemented for simple". Any ideas?

#36 Re: mORMot 1 » any possible that mORMot Framework be acquired by embarcadero someday » 2017-09-07 20:48:28


The mORMot acquisition by Embarcadero would be the worst event on my whole life.

#37 Re: mORMot 1 » Clear separation of components » 2017-07-05 08:19:24


Generally ORM systems are known as slow solutions but mORMot is fast so... maybe new namespace FastORM for ORM related stuff? I like dotted namespaces. So for me for example FastORM.Commons would be best wink. Anyway most important for me is separation to packages whatever the name is.

#38 Re: mORMot 1 » Clear separation of components » 2017-07-05 07:49:30


ab, did you forgot about our initial list of packages? tongue

mORMot_Commons, mORMot_SQLite3 (+ mORMot_SQLite3Static), mORMot_DB, mORMot_REST, mORMot_DDD, mORMot_MVC, mORMot_PDF, mORMot_UI, mORMot_CrossPlatform, mORMot_ZEOS

https://github.com/maciej-izak/mORMot/t … s/Packages

#39 mORMot 1 » Unhandled helpers in mustache » 2017-06-27 09:23:09

Replies: 0


current helpers without parameters are a little problematic:


will not work. we have workaround (additional fake parameter) which is not intuitive:

{{NewGUID call}}

I have small patch (parameter less helper is searched after context searching):


anyway maybe some other syntax for "parameter less" helpers may be better.

#41 mORMot 1 » TThreads problems for FPC... » 2017-06-09 10:28:05

Replies: 2


Is that possible that we have badly implemented threads in mORMot (especially for THttpApiServer.Destroy/TSynThreadPoolTHttpServer.Task)? The problem is really frustrating for me (finally mORMot is state of perfection). All which we have about problems:

https://synopse.info/forum/viewtopic.ph … 301#p24301

The problem was partially solved by this modification:
https://github.com/synopse/mORMot/blob/ … 5003-L5006

But still we have problems on shutting down TestSQL3 for FPC :\ (https://synopse.info/forum/viewtopic.ph … 301#p24301)

note: my report on FPC mantis (#31987 - https://bugs.freepascal.org/view.php?id=31987) may be improper :\.

#42 mORMot 1 » Unhandled FIN packet flag. » 2017-05-09 11:23:16

Replies: 0


I am working with TCP a little and during usage of mORMot (TDDDSocketThread exactly) I discovered the problem:


mORMot can't detect FIN flag (which means end of connection). May be worth to rethink implementation of SynCrtSock.InputSock. Some tip from stackoverflow:


I am unable to detect from TDDDSocketThread level packet with FIN flag (from client side). After FIN action (37) my server/client tries to send new packet (39) which is rejected (40) and data are lost. In this step (40) is executed TDDDSocketThread.InternalExecuteDisconnect which is not correct at all. The connection should be closed probably in step after FIN (38) - I guess: packet with ACK and FIN.

#43 Re: mORMot 1 » SynCrtSock significant bug » 2017-03-29 13:10:01


After many months of tracking logs from production server (~ 2 millions of http calls to server with SynLZ compression's per month from around ~10 devices), probably I discovered the reason of bug. Since in production environment I have less count of Samsung Galaxy Tab (IIRC Galaxy Tab 3 which has Exynos chipset) the bug occurs less often. All detected anomalies comes only from Samsung devices. From other device like "MyPhone hammer" (which has for sure different ARM processor model) I don't have problems with compression. The most important info about "impossible bug":

http://www.mono-project.com/news/2016/0 … 64-icache/
https://www.theregister.co.uk/2016/09/1 … e_gcc_bug/

ab, did you think that above problem could have influence on SynLZ compression for ARM?

#44 Re: mORMot 1 » Possible MVC blog demo regression » 2017-03-29 11:12:42


Finally works as expected smile. Btw. amazing experience: VPS server with own blog/small site with https without any "apache". Just Debian + FPC mORMot application + nginx on the front.

Did we have any plans to support HTTPS via SynOpenSSL in near future? If yes then probably will be possible to drop nginx (maybe not at all if someone needs load balancing)!

#45 Re: mORMot 1 » Possible MVC blog demo regression » 2017-03-27 20:47:43


Nice trick with /json, thanks smile. I think that we have problem in framework. "AuthorRights" works correctly only for FPC, Delphi (in my case XE2) shows


instead of

"AuthorRights": {
	"Comment": true,
	"Post": true,
	"Delete": true,
	"Administrate": true

ArticleView is still buggy in Delphi.

#46 Re: mORMot 1 » Possible MVC blog demo regression » 2017-03-27 08:34:57

hnb wrote:

I am not sure but probable we have regression for MVC demo

hmm. Seems that sample "30 - MVC Server" is broken for long time ("Add Comment" functionality is not displayed). Tested with latest mORMot on Delphi and FPC, also very old mORMot (I use for test purposes old version from 2015 January) is broken so this bug is not new :\ ...

#47 mORMot 1 » Possible MVC blog demo regression » 2017-03-26 23:27:41

Replies: 5


I am not sure but probable we have regression for MVC demo. The problem is visible for logged user (in this case synopse). Seems that Mustache won't work anymore for sets (like in ArticleView.html):


In case of "ArticleView.html view" the logged user can't comment articles anymore. Could someone confirm that?

#48 Re: mORMot 1 » Delphi 10.2 Tokyo Compatibility » 2017-03-23 10:06:50


I suppose that we have no plans to go for ARC Delphi compiler for Linux (which is only for Enterprise+ editions even for RAD Studio ... yikes).

#49 Re: Free Pascal Compiler » mORMot and FPC 3.0/3.1.1 » 2017-03-09 07:52:11

AOG wrote:

The trunk changes can be found here: http://wiki.freepascal.org/User_Changes_Trunk
I leave it to hnb to explain more about NewPascal, but in general, NewPascal is a very recent trunk without the dangers of trunk.

as AOG said: NewPascal is a very recent trunk without the dangers of trunk (for mORMot)

NewPascal is compatible with FPC trunk, but not vice versa (for some time).

Many things has changed. We have unexpected and positive effect of NewPascal - I've started close cooperation with FPC core team and finally many areas (critical for mORMot) are improved. Current list of differences between NewPascal and FPC: http://newpascal.org/compass.html

Very short list in section "NewPascal individual changes" may be expanded in the future. Each item in "NewPascal individual changes" should be merged with FPC trunk (sooner or later). Some time ago "NewPascal individual changes" list was much, much longer.

Please note that http://wiki.freepascal.org/User_Changes_Trunk is not yet updated (no info about newest RTTI changes and management operators - http://free-pascal-general.1045716.n5.n … 7716.html)

#50 Re: mORMot 1 » Lazarus 3.0.0 on win64 install » 2017-03-08 13:05:22

d.ioannidis wrote:

so if I understand correctly, even with those workarounds in place using fpc 3.0.2 and mORMot trunk is something you're advising against .

Am I correct ?

Yes. I can't wait for next FPC release (probably 3.2 or 4.0) which will be full of required features. 3.0.2 is too weak for mORMot and has only minor bugfixes (in comparison to 3.0.0).

Please note that even FPC pure trunk is bad choice because we have in plans to improve RTTI on many levels so you can't be sure which version of mORMot works correctly with yours FPC trunk. Only NewPascal contains tested mORMot with selected FPC trunk revision. NewPascal is safe buffer and meeting point between FPC and mORMot smile

Board footer

Powered by FluxBB