mORMot Open Source

It looks like BatchAdd and BatchDelete update the Version field but BatchUpdate does not..

Please find the tests in https://gist.github.com/martin-doyle/00 … ceac4698fc.

Sorry again. I apologize for the inconvenience.
I tested on Linux with FPC. For Windows {$apptype console} is missing. Updated the files again. Hope it works now. Thank you for taking care.

 Replication test suite
  ------------------------


1. Test suite

 1.1. Replication simple:
  - Test add: 45 assertions passed  46.93ms
  - Test update: 97 assertions passed  14.95ms
  - Test delete: 72 assertions passed  13.42ms
  Total failed: 0 / 214  - Replication simple PASSED  80.92ms

 1.2. Replication batch:
  - Test batch add: 4,011 assertions passed  42.88ms
!  - Test batch update: 10 / 7,038 FAILED  55.69ms
  - Test batch delete: 6,968 assertions passed  56.58ms
  Total failed: 10 / 18,017  - Replication batch FAILED  159.90ms

 1.3. Replication special:
  - Test add ten and delete first record: 77 assertions passed  12.38ms
!  - Test add ten and delete last record: 3 / 77 FAILED  11.63ms
!  - Test add one and delete record: 1 / 13 FAILED  11.41ms
  Total failed: 4 / 167  - Replication special FAILED  39.53ms


Generated with: Delphi 11.3 Alexandria 32 bit Win compiler

Time elapsed for all tests: 282.22ms
Performed 2023-06-05 21:33:25 by mdoyle on WIN11

Total assertions failed for all test suits:  14 / 18,398
! Some tests FAILED: please correct the code.

I created some tests in https://gist.github.com/martin-doyle/00 … ceac4698fc.
Hope that helps finding the issue and a fix.

Not sure what you try to accomplish with the Version field. I use it for master slave replication without any issues. Never checked the numbers but the result of the replication.
It is difficult helping you with this fragment of code. Please provide a working example. But please follow the forum rules and do not copy long code directly into the forum.
I do not understand your batch approach. Please check the documentation 12.3. The batch process is pretty straightforward and works for me.

The same happens when using one of the Create functions with paramters.

Order := TOrmOrderBook.Create(TestClient.Orm, 'OrderNo = ?', ['Order1']);

The work around is currently using the Retrieve function like

Order := TOrmOrderBook.Create;
  try
    TestClient.Orm.Retrieve('OrderNo = ?', [], ['Order1'], Order); 

I updated the tests in https://gist.github.com/martin-doyle/6c … a26990e46e.

By the way, I like the idea of embedding detail data within the record (sharding). Would be interesting to know what other people use, just schemaless TDocVariant?

I kept testing on MacOS aarch64.

First, I compiled the newest sqlite3 3.37.2 and the installation worked without any problem. Then I thought, maybe compiling the static libraries works as well. I could compile armv8.c from the res directory. This made building the mormot2 package possible.
Compiling the sqlite3 library was a little trickier. I had to patch the amalgamation file on Linux since „sed“ works a little different on MacOS.

To make a long story short, I could compile and run the mormot tests with static libraries.
I had to disable a couple of tests which froze but it is a good start. https://gist.github.com/martin-doyle/0f … e9dacdc252

A first issue I found was a segmentation fault when creating the BloomFilter. ln(fFalsePositivePercent / 100) crashes. ln(0.01) works just fine. I created a little fpc test program in order to see if it is a fpc, type whatever issue. But no problem here - ln seems to work as expected but behaves strangely within the Create method of Bloomfilter.

Oops. My VM had only 2 cores with 4 GB RAM.
For 4 cores and 8GB it looks like this https://gist.github.com/martin-doyle/e0 … 22075e6de0.

cat /proc/cpuinfo does not give any information about the cpu details only some cryptic numbers. sysctl -a machdep.cpu only works on the macOS terminal. Let me further check.

I ran the tests several times. Please find the numbers here https://gist.github.com/martin-doyle/8b … c7d68cfd7c.

The failed tests starting at 2.1 ORM Core seem to have the same root cause. The InMemory storage reading existing data - i.e. TTestOrmCore._TRestServerFullMemory line 299 - fails due to duplicate entries. TRestStorageInMemory.LoadFromBinariy loads all entries correctly but in ComputeStateAfterLoad it seems that the PtrInt dup variable is not set in/after fValues.Hasher.ForceReHash(@dup).

OK. I checked again my setup. FPC is available for aarch64 only since version 3.2.2.
First I cross compiled from FPC 3.2.0  Debian X64 to aarch64 and I did not get the above error messages. All Variant tests were fine.
Second I reinstalled FPC fixes-3.2 and Lazarus fixes-2.2 on Debian aarch64 with FPCUPdeluxe 2.2.0h. The installed versions are now FPC 3.2.3-582-gdba65567f1 and Lazarus 2.2.0-64-gff329cf453. And guess what, no Variant test issues anymore.
There are a few tests left which fail and I will keep checking. Thanks ab and Alfred for the great job.