Synopse

Another great video by warleyalex.

This time, a full FishFacts demo in AJAX, using mORMot and its SQLite3 ORM as server.

See it on YouTube!

Feedback is welcome on our forum.

Update:

I've just uploaded the corresponding source code to our repository.
See sample 19 - AJAX ExtJS FishFacts.
You need to download the corresponding DB file to run the sample.
Enjoy!

We have just added a TSQLTable.ToObjectList<T: class>() method.

I want to add some generics-based methods to mORMot, for newer versions of Delphi.

What do you think of it?
Have you some method prototypes to propose?

My first concern is that FreePascal does not offer the same syntax.
I suppose some $ifdef... will be necessary here..

Feel free to post your proposal to the forum.

Up to now, there is no official Win64 version of the SQlite3 library released in http://sqlite.org..
It is in fact very difficult to find a ready-to-use and up-to-date SQLite3-64.dll from Internet, for Win64.

You can find our own 3.7.16 version of the SQlite3 external library, to be used in 64 bit mode, to be downloaded from SQLite3-64.7z.

It includes FTS3/FTS4 virtual tables, and was compiled in release mode.

Compiled with the latest version of Rad Studio XE3, which uses the LLVM 64 bit compiler as back-end.
Thanks to Hans for compiling and sharing the binary!

This is the version we use when our mORMot framework targets Win64, using Delphi XE2/XE3.

With upcoming revision 1.18 of the framework, our SynSQlite3.pas unit is able to access the SQLite3 engine in two ways:

• Either statically linked within the project executable;
• Or from an external sqlite3.dll library file.

The SQLite3 APIs and constants are defined in SynSQlite3.pas, and accessible via a TSQLite3Library class definition. It defines a global sqlite3 variable as such:

var
  sqlite3: TSQLite3Library;

To use the SQLite3 engine, an instance of TSQLite3Library class shall be assigned to this global variable. Then all mORMot's calls will be made through it, calling e.g. sqlite3.open() instead of sqlite3_open().

There are two implementation classes:

Referring to SynSQLite3Static.pas in the uses clause of your project is enough to link the .obj engine into your executable.

Warning - breaking change: before version 1.18 of the framework, link of static .obj was forced - so you must add a reference to SynSQLite3Static in your project uses clause to work as expected.

In order to use an external sqlite3.dll library, you have to set the global sqlite3 variable as such:

 FreeAndNil(sqlite3); // release any previous instance (e.g. static)
 sqlite3 := TSQLite3LibraryDynamic.Create;

Of course, FreeAndNil(sqlite3) is not mandatory, and should be necessary only to avoid any memory leak if another SQLite3 engine instance was allocated (may be the case if SynSQLite3Static is referred somewhere in your project's units).

Here are some benchmarks, compiled with Delphi XE3, run in a 32 bit project, using either the static bcc-compiled engine, or an external sqlite3.dll, compiled via MinGW or Microsoft Visual C++.

Up to now, our SynDB database classes were handling ODBC, OleDB providers and direct Oracle or SQLite3 connection.

We have added a DB.pas based layer, ready to be used with UniDAC, NexusDB, or the BDE.
Any other TDataset based component is ready to be interfaced, including UIB, AnyDAC or DBExpress.

The ZEOS library (in its latest 7.0.3 stable version, which works from Delphi 7 up to XE3) has also been interfaced, but without the TDataset/DB.pas layer: our SynDBZEOS.pas unit calls the ZDBC layer, which is not tied to DB.pas nor its RAD components, and is therefore faster. By the way, it will work also with the Starter edition of Delphi (which does not include the DB components) - just like the other "regular" SynDB classes.

This is a work in progress, any testing and feedback is welcome!
We had to circumvent some particularities of the libraries, but I guess we have something interesting.

A dedicated "SynDBDataset" sub-folder has been created in the repository, to contain all SynDBDataset.pas-based database providers.
SynDBNexusDB.pas unit has been moved within this sub-folder, as SynDBUniDAC.pas + SynDBBDE.pas units have been added.
SynDBZeos.pas has a direct access to the ZDBC layer, so is not part of the "SynDBDataset" sub-folder.

Here is some benchmark, mainly about Oracle and SQlite3 database access.
Of course, our direct SynDBOracle / SynDBSQLite3 layers are the fastest around, and we can see that ZDBC layer is sometimes more efficient than the TDataset components.

Some major speed improvements have been made to our SynDB* units, and how they are used within the mORMot persistence layer.
It results in an amazing speed increase, in some cases.

Here are some of the optimizations how took place in the source code trunk:

• SQL statement client-side cache in ODBC and OleDB;
• SQL statement server-side cache for Oracle;
• When inserting individual data rows in an external table, the last inserted IDs are maintained in memory instead of executing "select max(id)" -  we added a new property EngineAddUseSelectMaxID to unset this optimization - we noted that this modification circumvented a known limitation of Firebird very efficiently.

Overall, I observed from x2 to x10 performance boost with simple Add() operations, using ODBC, OleDB and direct Oracle access, when compare to previous benchmarks (which were already impressive).
BATCH mode performance is less impacted, since it by-passed some of those limitations, but even in this operation mode, there is some benefits (especially with ODBC and OleDB).

Here are some results, directly generated by the supplied "15 - External DB performance" sample.

A long-time mORMot user and contributor just made a proposal on our forums.
He did use mORMot classes to integrate a SpiderMonkey JavaScript engine to our very fast and scaling HTTP server, including our optimized JSON serialization layer.

Today, he sent to me some of his source code, which sounds ready to be included in the main trunk!

This is a great contribution, and Pavel's goal is nothing less than offering
Delphi based, FAST multithreaded server with ORM and node.js modules compatible.

Due to the current implementation pattern of the TCollection type in Delphi, it was not possible to implement directly this kind of parameter.

In fact, the TCollection constructor is defined as such:

 constructor Create(ItemClass: TCollectionItemClass);

And, on the server side, we do not know which kind of TCollectionItemClass is to be passed. Therefore, the TServiceFactoryServer is unable to properly instantiate the object instances, supplying the expected item class.

The framework propose two potential solutions:

• You can let your collection class inherit from the new TInterfaceCollection type;
• You can call the TJSONSerializer.RegisterCollectionForJSON() method to register the collection type and its associated item class.

First solution has already been detailed in this blog.
We will now describe the second (and new) way.

Even if mORMot will be more easily used in a project designed from scratch, it fits very well the purpose of evolving any existing Delphi project, or even creating the server side part of an AJAX application. 

One benefit of such a framework is to facilitate the transition from a Client-Server architecture to a N-Tier layered pattern.

All former SQLite3\SQLite3*.pas units have been renamed to SQLite3\mORMot*.pas to match the database-agnostic scheme of the mORMot framework.

This is a major break change, so all your "uses" clauses in your code is to be change to follow the new naming.

See this commit, which includes documentation.
During the same winter cleaning, we get rid of the deprecated Zeos directory in our source code repository.

Now we are very close to the 1.18 release!
Don't hesitate to report any bug/issue/limitation as soon as possible!

Feedback is welcome on our forum.