Synopse

For those how are interested in FireMonkey, I made some screenshots of some DXScene sample app.

It may give you some good starting point about the features of the upcoming Delphi XE2 user interface components.

Everybody is buzzing about FireMonkey...

Our little mORMot will like FireMonkey!
Here is why...

Our ORM RESTful Framework is about to access any available database engine.

It will probably change its name (since it won't use only SQlite3 as database), to become mORMot - could be an acronym for "Manage Object Relational Mapping Over Tables", or whatever you may think of...

We'll still rely on SQLite3 on the server, but a dedicated mechanism will allow to access via OleDB any remote database, and mix those tables content with the native ORM tables of the framework. A flexible Virtual Tables and column mapping will allow any possible architecture: either a new project in pure ORM, either a project relying on an existing database with its own table layout.

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.

Here is what wikipedia states at http://en.wikipedia.org/wiki/Shared_nothing_architecture:

A shared nothing architecture (SN) is a distributed computing architecture in which each node is independent and self-sufficient, and there is no single point of contention across the system. People typically contrast SN with systems that keep a large amount of centrally-stored state information, whether in a database, an application server, or any other similar single point of contention.

This is just one approach of "sharding". Sharding is indeed related to a shared nothing architecture - once sharded, each shard can live in a totally separate logical schema instance.
"I sharded, therefore it scales"...

You can do this in Delphi... and opens a new world of scaling opportunities... Just as Google, Facebook, or eBay do... 

There is a well known syndrome around, against ORM.

Do you remember The Vietnam of Computer Science article?

It is worth reading... and commenting.
Sounds a bit outdated by now. Tempus fugit!

That's it, our SynOleDB unit seems alive and running well.

OLE DB (Object Linking and Embedding, Database, sometimes written as OLEDB or OLE-DB) is an API designed by Microsoft for accessing data from a variety of sources in a uniform manner. It was designed as a higher-level replacement for, and successor to, ODBC, extending its feature set to support a wider variety of non-relational databases, such as object databases and spreadsheets that do not necessarily implement SQL.

SynOleDB unit implementation has been made with several points in mind:

• Tested with SQL Server 2008 R2 and Oracle 11g providers from Microsoft and Oracle; 
• Ability to be truly Unicode, even with pre-Unicode version of Delphi (like Delphi 7 or 2007); 
• Could access any local or remote Database, from any version of Delphi, since it doesn't use the DB.pas unit or any related part of the VCL (even the Delphi 7 personal or the Turbo Explorer editions), just for free; 
• Handle NULL or BLOB content for parameters and results; 
• Avoid most memory copy or unnecessary allocation: we tried to access the data directly from the retrieved data buffer, just as given from OleDB; 
• Was therefore designed to achieve the best performance possible: most time is spent in OleDB: the code layer added to the OleDB customer is very thin; 
• True OOP architecture, to be used with any OleDB provider (allowing custom parameters or such), and even without OleDB (in the future, direct access to any DB client could be used); 
• Could be safely used in a multi-threaded application/server (with one TOleDBConnection per thread); 
• Allow parameter bindings of requests, with fast access to any parameter or column name (thanks to TDynArrayHashed);
• Late binding of column values in Delphi code;
• Direct JSON content creation, with no temporary data copy nor allocation; 
• Designed to be used with our mORMot ORM, but could be used stand-alone (a full Delphi 7 client executable is just about 200 KB), or even in any existing Delphi application, thanks to a TQuery-like wrapper.

After a question on StackOverflow, I wanted to comment about the speed of generated code by diverse Delphi compiler versions.

Since performance matters when we write general purpose libraries like ours, we have some feedback to propose:

• The 4,500,000 unitary tests of our SQlite3 ORM Framework;
• The SynLZ compression algorithm.

For our ORM, we needed a class variable to be available for each TSQLRecord class type.

This variable is used to store the properties of this class type, i.e. the database Table properties (e.g. table and column names and types) associated with a particular TSQLRecord class, from which all our ORM objects inherit.

The class var statement was not enough for us:
- It's not available on earlier Delphi versions, and we try to have our framework work with Delphi 6-7 up to XE;
- This class var instance will be shared by all classes inheriting from the class where it is defined - and we need ONE instance PER class type, not ONE instance for ALL

We needed to find another way to implement this class variable. 

An unused VMT slot in the class type description was identified, then each class definition was patched in the process memory to contain our class variable.

This is a major step for the framework.

Among a lot of new features and bug fixes:

• Dynamic arrays and Record handling, including low-level access and high-level handling for the ORM part of the framework (using TDynArray wrapper);
• Business rules now handled via filtering and validating classes for both our ORM and the Synopse Big Table;
• New full-featured logging classes, with exception handling, stack trace and JSON serialization;
• Custom SQL functions and TSQLRecordRTree to implement R-Tree virtual tables;
• Batch sequences for adding/updating/deleting multiple records;
• Secure RESTful authentication via per-user light sessions, and per-query signature;
• Define custom Virtual Tables (i.e. access any kind of data from SQL) in Delphi code;
• New HTTP server using fast http.sys kernel-mode server and zip / SynLZ compression;
• SynTaskDialog unit native under Vista,Seven with emulation code under XP/2000 ;
• User Interface automated Generation using standard VCL or proprietary TMS components;
• Documentation completed - more than 600 pages by now, including general User Guide and exhaustive Technical Reference;
• Updated SQLite3 database engine to version 3.7.6.3;
• Numerous bug fixes, speed and feature enhancements (including in the PDF and other UI-related units).

Open Source project, for Delphi 6 up to XE, licensed under a MPL/LGPL/GPL tri-license.