This is not just the cross-platform client library, but an Embedded
SQLite3 ORM stand-alone application running on the Android device!

Updated:You can download the
.apk directly from http://synopse.info/files/samples/mORMotSample.apk
Note how the application compiled with laz4android, using native
Android components, if much smaller than a FMX's.
The apk has two huge JPEG pictures, but the binary itself is only 800 KB...

You can use the FreePascal
Compiler (FPC) to compile the mORMot framework source code,
targetting Windows and Linux.

Linux is a premium target for cheap and efficient server
Hosting. Since mORMot has no dependency, installing a new
mORMot server is as easy as copying its executable on a blank
Linux host, then run it. No need to install any framework nor runtime.
You could even use diverse operating systems (several Linux or
Windows Server versions) in your mORMot servers farm, with
minimal system requirements, and updates.

We will now see how to write your software with Linux-compiling in mind, and
also give some notes about how to install a Linux Virtual Machine with
Lazarus on your Windows computer, compiling both FPC and
Lazarus from their SVN latest sources!

How would be 2015 like for our little rodents?
Due to popular request of several users of mORMot, we identified and
designed some feature requests dedicated to BigData process.

In fact, your data is the new value, especially if you propose
SaaS (Software As A Service)
hosting to your customers, with a farm of mORMot
servers.
Recent Linux support for mORMot servers, together with the
high performance and installation ease of our executable, open the gate to
cheap cloud-based hosting.
As a consequence, a lot of information would certainly be gathered by
your mORMot servers, and a single monolithic database
is not an option any more.

For mORMot solutions hosted in cloud, a lot of data may be
generated. The default SQLite3 storage engine may be less convenient,
once it reaches some GB of file content. Backup becomes to be slow and
inefficient, and hosting this oldest data in the main DB, probably stored on an
expensive SSD, may be a lost of resource. Vertical scaling is limited by
hardware and price factors.

This is were data sharding comes into scene.
Note that sharding is not replication/backup, nor clustering, nor just
spreading. We are speaking about application-level data splitting, to ease
maintenance and horizontal scalability of mORMot servers.

Data sharding could already be implemented with mORMot servers,
thanks to TSQLRestStorage:

Using TSQLRestStorageExternal: any table may have its own
external SQL database engine, may be in its separated DB server;

Using TSQLRestStorageMongoDB: any table may be stored on a
MongoDB cluster, with its own sharding abilities;

Using TSQLRestStorageRemote: each table may have its own
remote ORM/REST server.

But when data stored in a single table tends to grow without limit, this
feature is not enough.
Let's see how the close future of mORMot looks like.

Up to now, the TSQLRecord.ID property was defined in
mORMot.pas as a plain
PtrInt/NativeInt (i.e. Integer under
Win32), since it was type-cast as pointer for TSQLRecord published
properties.
We introduced a new TID type, so that the ORM primary key would
now be defined as Int64.

All the framework ORM process relies on the TSQLRecord
class.
This abstract TSQLRecord class features a lot of built-in methods,
convenient to do most of the ORM process in a generic way, at record level.

It first defines a primary key field, defined as ID:
TID, i.e. as Int64 in mORMot.pas:

It is pretty much possible that you would have to maintain and evolve a
legacy project, based on an existing database, with a lot of already written
SQL statements - see Legacy code and
existing projects.

If you use our little mORMot framework in any of your project,
commercial or not, please report it to a new
forum thread dedicated for this!
Sounds like if more and more projects are using our little rodent...
The cross-platform clients did increase its popularity, as far as I found out,
in the last days.

Furthermore, if you accept that your application is quoted in our framework
documentation and web site, and/or your logo displayed, please notify it in the
application post or by email to us.

Current version of the main framework units target only Win32 and
Win64 systems.

It allows to make easy self-hosting of mORMot servers for local
business applications in any corporation, or pay cheap hosting in the Cloud,
since mORMot CPU and RAM expectations are much lower than a regular
IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need
to create clients for platforms outside the Windows world, especially
mobile devices.

A set of cross-platform client units is therefore available in the
CrossPlatform sub-folder of the source code repository. It allows
writing any client in modern object pascal language, for:

Any version of Delphi, on any platform (Mac OSX, or any
mobile supported devices);

Current version of the main framework units target only Win32 and
Win64 systems.

It allows to make easy self-hosting of mORMot servers for local
business applications in any corporation, or pay cheap hosting in the Cloud,
since mORMot CPU and RAM expectations are much lower than a regular
IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need
to create clients for platforms outside the Windows world, especially
mobile devices.

A set of cross-platform client units is therefore available in the
CrossPlatform sub-folder of the source code repository. It allows
writing any client in modern object pascal language, for:

Any version of Delphi, on any platform (Mac OSX, or any
mobile supported devices);

By default, interface-based services of a mORMot server will always
return a JSON array (or a JSON object, if
TServiceFactoryServer.ResultAsJSONObject is
true).
With some kind of clients (e.g. if they are made by a third party), it could be
useful to return XML content instead.

Your mORMot server is able to let its interface-based
services return XML context instead, or in addition to the default JSON
format.

Current framework RoadMap and implementation is in fact going into
a pragmatic direction.
No need to make all framework's unit compatible at once: so we introduced some
client-dedicated units, without any dependency on SynCommons.pas.

Since most CRUD operations are centered within the scope of our
mORMot server, we implemented in the ORM an integrated mean of
tracking changes (aka Audit Trail) of any TSQLRecord.
In short, our ORM is transformed into a time-machine, just like the good old
DeLorean!

Keeping a track of the history of business objects is one very common need
for software modeling, and a must-have for any accurate data modeling,
like Domain-Driven Design.
By default, as expected by the OOP model, any change to an object will forget
any previous state of this object. But thanks to mORMot's exclusive
change-tracking feature, you can persist the history of your objects.

Enabling audit-trail

By default, change-tracking feature will be disabled, saving performance and
disk use.
But you can enable change tracking for any class, by calling the following
method, on server side:

aServer.TrackChanges([TSQLInvoice]);

This single line will let aServer: TSQLRestServer monitor all
CRUD operations, and store all changes of the TSQLInvoice table
within a TSQLRecordHistory table.

From the beginning, server-side storage tables which were not store in
a SQLite3 database were implemented via some classes
inheriting from TSQLRestServerStatic.
This TSQLRestServerStatic was inheriting
from TSQLRestServer, which did not make much sense (but was
made for laziness years ago, if I remember well).

Now, a new TSQLRestStorage class, directly inheriting from
TSQLRest, is used for per-table storage.
This huge code
refactoring results in a much cleaner design, and will enhance code
maintainability.
Documentation has been updated to reflect the changes.

Note that this won't change anything when using the framework (but the new
class names): it is an implementation detail, which had to be fixed.

MongoDB appears as a serious competitor to SQL databases, with the
potential benefit of horizontal scaling and installation/administration ease -
performance is very high, and its document-based storage fits perfectly with
mORMot's advanced ORM features like Shared nothing architecture (or
sharding).

MongoDB (from "humongous") is
a cross-platform document-oriented database system, and certainly the best
known NoSQL database.
According to http://db-engines.com in April
2014, MongoDB is in 5th place of the most popular types of database
management systems, and first place for NoSQL database management
systems.
Our mORMot gives premium access to this database, featuring full
NoSQL and Object-Document Mapping (ODM) abilities to the
framework.

Integration is made at two levels:

Direct low-level access to the MongoDB server, in the
SynMongoDB.pas unit;

Close integration with our ORM (which becomes defacto an ODM), in
the mORMotMongoDB.pas unit.

This is a great opportunity to discovers some patterns you may not be
familiar with, and find out how mORMot try to implement them.
This set of slides may be less intimidating than our huge documentation - do
not be terrified by our
Online Documentation!
The
first set of pages (presenting architecture and design principles) is worth
reading.

Purpose here is not to say that one library or database is better or
faster than another, but publish a snapshot of mORMot persistence
layer abilities, depending on each access library.

In this timing, we do not benchmark only the "pure" SQL/DB layer access
(SynDB units), but the whole Client-Server ORM of our
framework.

Process below includes all aspects of our ORM:

Access via high level CRUD methods (Add/Update/Delete/Retrieve,
either per-object or in BATCH mode);

Read and write access of TSQLRecord instances, via optimized
RTTI;

JSON marshaling of all values (ready to be transmitted over a
network);

REST routing, with security, logging and statistic;

Virtual cross-database layer using its SQLite3 kernel;

SQL on-the-fly generation and translation (in virtual mode);

Access to the database engines via several libraries or providers.

In those tests, we just bypassed the communication layer, since
TSQLRestClient and TSQLRestServer are run in-process,
in the same thread - as a TSQLRestServerDB instance. So you have
here some raw performance testimony of our framework's ORM and RESTful core,
and may expect good scaling abilities when running on high-end hardware, over a
network.

On a recent notebook computer (Core i7 and SSD drive), depending on
the back-end database interfaced, mORMot excels in speed, as will show
the following benchmark:

You can persist up to 570,000 objects per second, or retrieve 870,000
objects per second (for our pure Delphi in-memory engine);

When data is retrieved from server or client 38, you can read more than
900,000 objects per second, whatever the database back-end is;

With a high-performance database like Oracle, and our direct access
classes, you can write 70,000 (via array binding) and read 160,000 objects per
second, over a 100 MB network;

When using alternate database access libraries (e.g. Zeos, or
DB.pas based classes), speed is lower (even if comparable for DB2,
MS SQL, PostgreSQL, MySQL) but still enough for most work, due to some
optimizations in the mORMot code (e.g. caching of prepared statements,
SQL multi-values insertion, direct export to/from JSON, SQlite3
virtual mode design, avoid most temporary memory allocation...).

We just committed some nice features to the ORM kernel, and SynDB*
classes of our mORMot framework.

During BATCH
insertion, the ORM is able to generate some optimized SQL statements,
depending on the target database, to send several rows of data at once.
It induces a noticeable speed increase when saving several objects into an
external database.

This feature is available for SQlite3 (3.7.11 and later),
MySQL, PostgreSQL, MS SQLServer (2008
and up), Oracle, Firebird and NexusDB.
Since it is working at SQL level, it is available for all supported access
libraries, e.g. ODBC, OleDB, Zeos/ZDBC, UniDAC,
FireDAC.
It means that even properties not implementing array binding (like OleDB,
Zeos or UniDAC) are able to have a huge boost at data insertion,
ready to compete with the
(until now) more optimized libraries.

One of the main features you may miss when discovering NoSQL ("Not-Only
SQL"?) databases, coming from a RDBMS background, is ACID.

ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties
that guarantee that database transactions are processed reliably. In the
context of databases, a single logical operation on the data is called a
transaction. For example, a transfer of funds from one bank account to another,
even involving multiple changes such as debiting one account and crediting
another, is a single transaction. (Wikipedia)

Whatever document/key/column oriented they are, they all use some kind of
document storage.
It may be schema-less, blob-stored, column-driven, but it is always some set of
values bound together to be persisted.
This set of values define a particular state of one entity, in a given
model.
Which we may call Aggregate.

With revision 1.18 of the framework, we just introduced two new custom types
of variants:

TDocVariant kind of variant;

TBSONVariant kind of variant.

The second custom type (which handles MongoDB-specific extensions -
like ObjectID or other specific types like dates or binary) will
be presented later, when dealing with MongoDB support in
mORMot, together with the BSON kind of content. BSON /
MongoDB support is implemented in the SynMongoDB.pas
unit.

We will now focus on TDocVariant itself, which is a generic
container of JSON-like objects or arrays.
This custom variant type is implemented in SynCommons.pas unit, so
is ready to be used everywhere in your code, even without any link to the
mORMot ORM kernel, or MongoDB.

TDocVariant documents

TDocVariant implements a custom variant type which can be used
to store any JSON/BSON document-based content, i.e. either:

Name/value pairs, for object-oriented documents;

An array of values (including nested documents), for array-oriented
documents;

Any combination of the two, by nesting TDocVariant
instances.

Here are the main features of this custom variant type:

DOM approach of any object or array documents;

Perfect storage for dynamic value-objects content, with a
schema-less approach (as you may be used to in scripting languages
like Python or JavaScript);

Allow nested documents, with no depth limitation but the available
memory;

Assignment can be either per-value (default, safest but slower
when containing a lot of nested data), or per-reference (immediate
reference-counted assignment);

Very fast JSON serialization / un-serialization with support of
MongoDB-like extended syntax;

Access to properties in code, via late-binding (including almost no speed
penalty due to our VCL hack as already detailed);

Direct access to the internal variant names and values
arrays from code, by trans-typing into a TDocVariantData
record;

Instance life-time is managed by the compiler (like any other
variant type), without the need to use interfaces or
explicit try..finally blocks;

Optimized to use as little memory and CPU resource as possible (in contrast
to most other libraries, it does not allocate one class instance
per node, but rely on pre-allocated arrays);

Opened to extension of any content storage - for instance, it will
perfectly integrate with BSON serialization and custom MongoDB types
(ObjectID, RegEx...), to be used in conjunction with MongoDB
servers;

Designed to work with our mORMot ORM: any TSQLRecord
instance containing such variant custom types as published
properties will be recognized by the ORM core, and work as expected with any
database back-end (storing the content as JSON in a TEXT column);

Designed to work with our mORMot SOA: any interface-based
service is able to consume or publish such kind of content, as
variant kind of parameters;

Fully integrated with the Delphi IDE: any variant instance
will be displayed as JSON in the IDE debugger, making it very convenient to
work with.

To create instances of such variant, you can use some
easy-to-remember functions:

Our Synopse mORMot Framework was designed in accordance with
Fielding's REST
architectural style without using HTTP and without interacting with the
World Wide Web.
Such Systems which follow REST principles are often referred to as
"RESTful".

Optionally, the Framework is able to serve standard HTTP/1.1 pages over the
Internet (by using the mORMotHttpClient / mORMotHttpServer units
and the TSQLHttpServer and TSQLHttpClient classes),
in an embedded low resource and fast HTTP server.