mORMot Open Source

This is exactly what the open-source community is all about! Congrats on mastering mORMot 2 and Free Pascal. Your persistence and willingness to learn are a great example for all of us. Thanks for being part of this journey! ❤️

Ran the body-input-stream branch on real hardware, as promised: Rockchip RK3588 (aarch64-linux, FPC 3.2.3), THttpAsyncServer with OnBodyDownload spooling to a temp file (TFileStreamEx + TemporaryFileName), the handler renaming the spool file to take ownership. Client: curl from a LAN Windows box, payload = our real 111 MB firmware upgrade package.

scenario                                       result
---------------------------------------------  ---------------------------------------------------
single 111 MB upload                           OK - MD5 matches end to end, 3.2 s on gigabit LAN
4 concurrent (1x 111 MB + 3x 20 MB)            OK - all MD5s match, no temp-file collisions,
                                               no leftovers
slow link (--limit-rate 1M, 20 MB)             OK - MD5 matches
client killed mid-transfer (~30 of 111 MB)     OK - the half-written spool file was removed by
                                               the server within ~7-22 s after the disconnect,
                                               nothing ever reached the target folder, and the
                                               server kept serving
disk full (spool dir on a 40 MB tmpfs via      spool space fully reclaimed within seconds, the
TMPDIR, uploading 111 MB)                      server stayed alive and functional - but the
                                               client got a raw connection reset (curl exit 56,
                                               no HTTP status), see below

Two observations:

- on ENOSPC the connection is simply reset, so the client gets no HTTP response at all. Would it be worth sending e.g. 507 Insufficient Storage (or plain 500) before closing, when writing to the destination stream fails? For an upgrade-package UI the distinction between "server out of disk" and "network broke" is quite valuable.

- the spool cleanup after a hard client disconnect is not immediate (measured between 7 and 22 s later) - perfectly fine for us, just documenting the observed behavior.

Nice work - this fits our use case exactly. TMPDIR being honored by TemporaryFileName() also made the disk-full isolation easy.

Progress update: the first-stage PR is submitted — PR #506, https://github.com/synopse/mORMot2/pull/506 (TMvcViewsMustache.OnTranslate, wiring the built-in {{"text}} channel for MVC apps, with test).

Once it is merged, we will proceed as planned with the second-stage PR — the mormot.core.i18n unit itself, following the sketch and the three open questions from the opening post.

Congrats to Arnaud! Well earned this award!

Wow, these 10 practical skills are truly excellent and highly useful. They can effectively make AI-generated programs more consistent and compliant with the mORMot-Style specifications! I sincerely appreciate the hard work and outstanding development efforts from flydev. When it comes to the overall process framework design and construction, I personally highly recommend the BMAD Method. That’s right, I have fully migrated from superpower to this framework long ago. Although its overall structure is more complex, it is completely worthwhile once you become proficient in using it.

Thank you Chaa, but TSynFPUException.ForLibraryCode cannot solve this issue.

  Our program structure is:

  // Main thread (FPC)
  TS_Init(apiKey, callback);     // Initialize SDK (libvct.so)
  TS_createTask(taskConfig);     // Create transcoding task
  // Main thread now waits for callback...
  while not Terminated do
    Sleep(10);

  The SDK (libvct.so) is a C library that internally uses GStreamer and FFmpeg. When we call TS_createTask(), the function returns immediately. The actual transcoding happens asynchronously inside libvct.so's internal threads.

  The crash occurs like this:

  Main Thread (FPC):              SDK Internal Threads:
    TS_Init()
    TS_createTask() ------>  libvct.so creates worker threads
    waiting...                    |
    waiting...                    v
    waiting...               GStreamer/FFmpeg processing
    waiting...                    |
    waiting...                    v
                             Thread "queue210:src" calls pow()
                             -> resolves to mORMot's p0w()
                             -> FPC ThreadVar not initialized
                             -> CRASH

  We cannot wrap our SDK calls with TSynFPUException.ForLibraryCode:

  with TSynFPUException.ForLibraryCode do begin
    TS_createTask(taskConfig);  // Returns immediately!
  end;
  // ForLibraryCode scope ends here, but crash happens
  // much later in a different thread we don't control

  The ForLibraryCode pattern only works when the C code executes synchronously in the calling thread. It cannot help when the C library spawns its own threads that later call pow().

  This is why we need a fix in mORMot itself - either a define like -dNOLIBCMATH or making the exported functions safe for uninitialized threads.

docs: update JSON wiki for mORMot 2.4 delimiter syntax support

- Update version info from 2.3 to 2.4 (version 2.4.13376) in all 15 chapters
- Add "Creating Nested Structures" section in Chapter 3 documenting:
  - Delimiter syntax: '{' '}' '[' ']' in DocDict/DocList
  - .AsVariant approach for nested structures
  - Direct IDocDict/IDocList parameters
- Add FAQ Q17 about delimiter syntax support in DocDict/DocList
- Document feature parity between JsonEncode() and DocDict/DocList

Access: https://github.com/zen010101/Claude_Mor … sing-Guide

Thank you ab for the valuable feedback! I have updated the JSON wiki documentation accordingly:

  1. Delimiter Syntax Clarification

  Fixed the documentation to clarify that `'{' '}' '[' ']'` delimiter syntax is supported by `JsonEncode()` only, NOT by `DocDict()`/`DocList()`. All examples now correctly use `.AsVariant` for nesting:

  // CORRECT for DocDict/DocList
  dict := DocDict([
    'user', DocDict([
      'name', 'Alice',
      'roles', DocList(['admin', 'user']).AsVariant
    ]).AsVariant
  ]);

  2. SOA Service Best Practices

  Added documentation recommending RawJson + JsonEncode() for SOA interface-based services instead of IDocDict/IDocList:
  - New section in Chapter 3: "SOA Service Considerations"
  - New FAQ Q16: "Should I use IDocDict/IDocList in SOA service methods?"
  - Notes added to API response examples

  3. FPC Stable RTTI Registration

  - Rtti.RegisterType() is NOT enough for FPC stable or older Delphi
  - Must use Rtti.RegisterFromText() with manual field description

  Thanks again for the corrections!

Good idea, the wiki can also be managed by multiple people collaboratively using git. However, we can wait until I generate more articles later and then move them over uniformly.

Use ChangeSqlEncryptTablePassWord() function from mormot.db.raw.sqlite3.static unit:

     ChangeSqlEncryptTablePassWord('mydata.db3', 'OldPassword', 'NewPassword');

  Notes:
  - Database file must be closed before calling this function
  - To check if a file is encrypted: IsSQLite3FileEncrypted('mydata.db3')

  Don't forget to back up your database before the test!!!

In mORMot 2, SQLite3 encryption is built into the static library. Here's how to use it:

  1. Download static files from https://synopse.info/files/mormot2static.7z
  2. Add mormot.db.raw.sqlite3.static to your uses clause
  3. Pass password when creating the database:

  uses
    mormot.db.raw.sqlite3.static,
    mormot.orm.sqlite3;

  var
    Model: TOrmModel;
    Rest: TRestServerDB;
  begin
    Model := TOrmModel.Create([...]);
    Rest := TRestServerDB.Create(Model, 'mydata.db3', False, 'MyPassword');

  Or with TSqlDatabase directly:
  DB := TSqlDatabase.Create('mydata.db3', 'MyPassword');

  Important notes:
  - This encryption is NOT compatible with official SQLite SEE or wxsqlite3
  - NOT compatible with old mORMot 1 format (before 1.18.4413) - use OldSqlEncryptTablePassWordToPlain() to migrate
  - Uses AES-128 with PBKDF2 key derivation

I see your ComputeFieldsBeforeWrite implementation:

  NextID := aRest.TableMaxID(TOrmUser) + 1;
  if (aOccasion = oeAdd) and ((FInviteCode = '') or (NextID <= 3)) then
    FInviteCode := GenerateUniqueInviteCode(NextID);

  Issues:

  1. Race condition — TableMaxID + 1 is unreliable under concurrent inserts. Two users registering simultaneously may get the same NextID, causing duplicate invite codes.
  2. Database query in ComputeFieldsBeforeWrite — This method is called during the write operation. Querying TableMaxID here adds latency and potential deadlocks.

  Recommended fix:

  Generate the invite code after the record is inserted, when you have the actual ID:

  // In your registration service:
  function TDomainUserManager.RegisterUser(...): TID;
  begin
    Result := fOrm.Add(aUser, True);  // Insert first, get real ID
    if Result > 0 then
    begin
      aUser.IDValue := Result;
      aUser.InviteCode := GenerateUniqueInviteCode(Result);
      fOrm.Update(aUser, 'InviteCode');  // Update only this field
    end;
  end;

  Or use a UUID-based invite code that doesn't depend on ID:

  FInviteCode := Int64ToHex(Random64) + Int64ToHex(Random64);  // 32-char hex

  Also, what's the purpose of NextID <= 3? If it's for seeding admin accounts, consider handling that separately in InitializeTable.

● Hi testgary,

  I reviewed your code using Claude and created a feedback issue on your repository:
  https://github.com/pit500081/mormot2test/issues/1

  Summary of your 4 questions:

  Q1 - TUserRec for inter-layer communication:
  Good approach. Separating TOrmUser from DTO is correct. However, TUserRec has 23 fields serving too many purposes. Consider splitting into smaller DTOs like TUserProfileRec, TUserLoginResultRec, etc.

  Q2 - Captcha in CookieData:
  Security concern. Captcha text should NOT be stored client-side (even encrypted). Move to server-side storage using TSynDictionary (Token → CaptchaText mapping). Delete after verification to prevent replay attacks.

  Q3 - Separate modules for API and Web:
  Architecture is correct - both layers sharing IDomainUserManager is the right design. However:
 

• REST layer (TRestUserManager.Register) is empty - needs implementation

• MVC layer is too bloated - Register/Login methods handle captcha, session, validation, response formatting all in one. Extract into separate services (TCaptchaService, etc.) for better testability

  Q4 - Overall strategy:
  Solid foundation. Well done:
 

• Password hashing with mcfSCrypt

• Layered architecture (Repo → Domain → Presentation)

• Dependency injection via interfaces

• Extends TAuthUser properly

  Issues to fix:
 

• GetGroupEnum bug in user.repo.impl.pas:55-56 - SizeOf(TUserGroupTypeEnum) returns 1, not enum count

• LoginAt/LoginIp not updated on successful login

• No brute-force protection - add login attempt rate limiting

  The architecture is sound - these are refinements rather than fundamental changes.

Great work!

I'm not sure if everyone needs it. I can put it in my repo for a while first.

initialization
    // Register RTTI before any CSV parsing
    Rtti.RegisterFromText([TypeInfo(TCsvItem), _TCsvItem]);

https://github.com/zen010101/Claude_Mor … array-demo

I started using Serena + pasLS (LSP Server for Pascal) for semantic search yesterday. It is included in the Claude Code Plugin store, and I think the effect is quite good. Of course, the official Serena does not support the Pascal/Delphi language. I have made some modifications, and after a test is completed, I will submit a PR to merge into the official master branch. Below is a list of mORMot 2 functions related to RawUtf8: https://gist.github.com/zen010101/3b27c … f89625fe6e

===========================================
  Async Task Demo Client
  Demonstrates polling pattern
===========================================

Connected to server

Enter task duration in seconds (1-60): 10

Starting task with 10 second duration...
(Server timeout is 60s, but polling keeps session alive)

Task started with ID: 1

Status: Running... Progress: 4%
Status: Running... Progress: 9%
Status: Running... Progress: 14%
Status: Running... Progress: 20%
Status: Running... Progress: 25%
Status: Running... Progress: 29%
Status: Running... Progress: 35%
Status: Running... Progress: 40%
Status: Running... Progress: 45%
Status: Running... Progress: 50%
Status: Running... Progress: 55%
Status: Running... Progress: 60%
Status: Running... Progress: 65%
Status: Running... Progress: 71%
Status: Running... Progress: 75%
Status: Running... Progress: 80%
Status: Running... Progress: 86%
Status: Running... Progress: 90%
Status: Running... Progress: 95%
Status: COMPLETED!
Result: {"taskId":1,"taskName":"DemoTask","duration":10,"completedAt":"2025-12-17T19:51:42"}

Task finished!

Active tasks on server: 0

Press Enter to exit...

I'm really glad you like this article. Actually, I'm thinking about expanding this content into a full wiki in the form of FAQ + technical reviews, but it all depends on my spare time. If I get enough free time, I'll definitely keep enriching the wiki with more detailed and practical content.

Hah, that's only because your AI-friendly comments are so well-written that even the AI can "get" mORMot quickly -- it's like you left a super clear treasure map, and my AI tools just followed the lines faster than I could read them myself.

Maybe we can generate many simpler examples using Claude Code and merge them into the master branch

another demo, tested with FPC:

https://gist.github.com/zen010101/4af9a … ebe62f19a9

Usage:

  var
    Rec: TMyRecord;
  begin
    // ... populate Rec ...

    // Convert from UTC to GMT+8
    ConvertRecordDateTimesToTimezone(Rec, TypeInfo(TMyRecord), 8);

    // Convert from UTC to EST (GMT-5)
    ConvertRecordDateTimesToTimezone(Rec, TypeInfo(TMyRecord), -5);
  end;

I really like this version. Even if it doesn't end up being selected as the official version, please keep it.

Thank you again, Javierus, for presenting us with such concise and impactful mORMot 2 materials. I believe this will help many people.