Synopse

Our Client-Server ORM framework is now available in revision 1.15.

This is a major upgrade of the framework:

• It is now called mORMot - so please update your T-Shirts or coffee cups
• It is able to use any Database engine back-end - in fact, it is SQLite3 powered, not SQLite3 limited;
• In particular, direct OleDB and native Oracle have been implemented;
• It makes use of the genuine SQlite3 Virtual Table mechanism everywhere to allow mixed access to any database engine;
• New TModTime / TCreateTime kind of fields;
• Enhanced stability, speed and multi-thread implementation;
• Methods and functions have been enhanced, according to user feedback (thanks you all for your interest and forum posts!);
• Extended documentation (more than 700 pdf pages), with new diagrams and a lot of new content;
• New associated tools, like LogViewer or SynDBExplorer;
• The SQLite3 core can now be used without our ORM - it has been updated to the latest 3.7.8 version;
• Open Source (under GPL/LGPL/MPL license), running from Delphi 6 up to XE2.

Our downloadable documentation has been enhanced, and contains now a description about the main feature of the near-to-come 1.15 version, i.e. "database agnosticism".

The core database of our mORMot / SQLite3 framework uses the SQLite3 library, which is a Free, Secure, Zero-Configuration, Server-less, Single Stable Cross-Platform Database File database engine.

As stated below, you can use any other database access layer, if you wish. A fast in-memory engine is included, and can be used instead or together with the SQLite3 engine. Since revision 1.15 of the framework you may be able to access any remote database, and use one or more OleDB (or Oracle) connections to store your precious ORM objects. The SQlite3 will be used as the main SQL engine, able to JOIN all those tables, thanks to its Virtual Table unique feature.

For our upcoming mORMot framework, and in completion to our SynOleDB unit, we just added a new Open Source unit, named SynDBOracle. It allows direct access to any remote Oracle server, using the Oracle Call Interface.

Oracle Call Interface (OCI) is the most comprehensive, high performance, native unmanaged interface to the Oracle Database that exposes the full power of the Oracle Database. We wrote a direct call of the oci.dll library, using our DB abstraction classes introduced for SynOleDB.

We tried to implement all best-practice patterns detailed in the official Building High Performance Drivers for Oracle document

Resulting speed is quite impressive: for all requests, SynDBOracle is 3 to 5 times faster than a SynOleDB connection using the native OleDB Provider supplied by Oracle. We noted also that our implementation is 10 times faster than the one provided with ZEOS/ZDBC, which is far from optimized.

You can use the latest version of the Oracle Instant Client provided by Oracle - see this link - which allows you to run your applications without installing the standard (huge) Oracle client or having an ORACLE_HOME. Just deliver the dll files in the same directory than your application, and it will work.

For both our SynOleDB and SynBigTable units, we allow late-binding of data row values, using a variant and direct named access of properties. Thanks to this unique feature (as far as I know in the Delphi database world),

This allows clear and valid code as such:

var Customer: Variant;
begin
  with Props.Execute(
    'select * from Sales.Customer where AccountNumber like ?',
    ['AW000001%'],@Customer) do
    while Step do
      assert(Copy(Customer.AccountNumber,1,8)='AW000001');
end;

In practice, this code is slower than using a standard property based access, like this:

    while Step do
      assert(Copy(Column['AccountNumber'],1,8)='AW000001');

But the first version, using late-binding of column name, just sounds more natural.

Of course, since it's late-binding, we are not able to let the compiler check at compile time for the column name. If the column name in the source code is wrong, an error will be triggered at runtime only. But it would not be an issue, since it would be the same for the SQL code inserted: it's only executed at runtime (this is one of the benefits of using an ORM, by the way: the ORM will generate correct SQL code for you...).

The default VCL implementation of this late-binding was a bit slow for our purpose.
Since it has to deal with Ole Automation, and because it's fun, we hacked the VCL to provide a lighter and faster version for our custom variant types.

Our ORM framework has been released as version 1.14.

It's mainly a bug-fix release:

• Integrated SQLite3 engine updated to latest version 3.7.7.1;
• Fix several issues about JSON generation layout;
• Enhanced automated User Interface generation for object on-screen edition;
• SynPdf unit now handles Bézier curves from TCanvas, and some CMYK functions; also enhanced PDF/A-1compatibility;
• Some speed enhancements, and new functions for the SynOleDB unit.