We identified and fixed today several issues which may affect applications creating a lot of threads (i.e. not using a thread pool). The symptom was an unexpected access violation, when you reach a multiple of 256 threads count. You should better upgrade to at least revision 1.18.1351 if your […]
Usually, in Delphi application (like in most high-level languages), errors
are handled via exceptions. By default, any
raised on the server side, within an
method, will be intercepted, and transmitted as an error to the client side,
then a safe but somewhat obfuscated
will be raised on the client side, containing additional information serialized
You may wonder why exceptions are not transmitted and raised directly on the client side, with our mORMot framework interface-based services, as if they were executed locally.
We will now detail some arguments, and patterns to be followed.
As stated during
TSQLRecord fields definition, the ORM is able to maintain a revision
number for any
TSQLRecord table, so that it the table may be
easily synchronized remotely by another
If you define a
TRecordVersion published property, the ORM core
will fill this field just before any write with a monotonically increasing
revision number, and will take care of any deletion, so that those
modifications may be replayed later on any other database.
This synchronization will work as a strict master/slave replication
scheme, as a one-way on demand refresh of a replicated table.
Each write operation on the master database on a given table may be easily reflected on one or several slave databases, with almost no speed nor storage size penalty.
The mORMot framework documentation, in its HTML online form, has been enhanced to include links to almost of the code symbols. In fact, the latest version of our SynProject tool will search for code symbols (types, methods, constants, functions): Everywhere in the API Reference pages; In the text […]
I just received a mail from Alfred (aka Alf in the source code), which did a lot of work to let our little mORMot compiles and run with FPC, especially under Linux, and also with an ARM processor. Hello Arnaud, A nice surprise ... Sample 2 native on Android !!!! See picture. Works 100% !!! […]
2015-01-15. Open Source
Today, we committed a new patch to enable AES-NI hardware acceleration to our SynCrypto.pas unit. Intel® AES-NI is a new encryption instruction set that improves on the Advanced Encryption Standard (AES) algorithm and accelerates the encryption of data on newer processors. Of course, all this is […]
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
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,
TSQLRestStorageExternal: any table may have its own external SQL database engine, may be in its separated DB server;
TSQLRestStorageMongoDB: any table may be stored on a MongoDB cluster, with its own sharding abilities;
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.
You know that our mORMot is able to access directly any MongoDB database engine, allowing its ORM to become an ODM, and using NoSQL instead of SQL for the query languages.
But at mORMot level, you could share the same code between your
RDBMS and NoSQL databases.
The ORM/ODM is able to do all the conversions by itself!
Since we have just improved this feature, it is time to enlighten its current status.
In order to enhance code modularity, we extracted logging and testing features from SynCommons.pas. Discover the new SynLog.pas and SynTests.pas units! Documentation has been updated to reflect the changes. This is a breaking change... Ensure you add SynLog and/or SynTests to your uses clauses, just […]
We just finished our Be-Delphi 2014 sessions and drank our last beers, so here we are.
I published some slides for this great event.
For mORMot, we developed a fully feature direct access layer to any RDBMS, implemented in the SynDB.pas unit.
You can use those
SynDB classes to execute any SQL statement,
without any link to the framework ORM.
At reading, the resulting performance is much higher than using the standard
TDataSet component, which is in fact a true performance
It has genuine features, like column access via late-binding, an innovative
ISQLDBRows interface, and ability to directly access
the low-level binary buffers of the database clients.
We just added a nice feature to those classes: the ability to access
remotely, via plain HTTP, to any
SynDB supported database!
Up to now, the
TSQLRecord.ID property was defined in
mORMot.pas as a plain
Win32), since it was type-cast as pointer for
We introduced a new
TID type, so that the ORM primary key would
now be defined as
All the framework ORM process relies on the
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
TID, i.e. as
type TID = type Int64; ... TSQLRecord = class(TObject) ... property ID: TID read GetID write fID; ...
In fact, our ORM relies now on a
Int64 primary key, matching
RowID primary key.
This primary key will be used as RESTful resource identifier, for all CRUD operations.
Working with objects is pretty powerful, but requires to handle manually the
created instances life time, via
blocks. Most of the time, the
TSQLRecord life time would be very
short: we allocate one instance on a local variable, then release it when it
goes out of scope.
If we take again the
TSQLBaby sample, we may write:
function NewMaleBaby(Client: TSQLRest; const Name,Address: RawUTF8): TID; var Baby: TSQLBaby; // store a record begin Baby := TSQLBaby.Create; try Baby.Name := Name; Baby.Address := Address; Baby.BirthDate := Date; Baby.Sex := sMale; result := Client.Add(Baby); finally Baby.Free; end; end;
To ease this pretty usual pattern, the framework offers some kind of
automatic memory management at
function NewMaleBaby(Client: TSQLRest; const Name,Address: RawUTF8): TID; var Baby: TSQLBaby; // store a record begin TSQLBaby.AutoFree(Baby); // no try..finally needed! Baby.Name := Name; Baby.Address := Address; Baby.BirthDate := Date; Baby.Sex := sMale; result := Client.Add(Baby); end; // local Baby instance will be released here
We have enhanced our SynProject Open Source tool, so that it is now able to generate its documentation as HTML, in addition to doc/pdf documents. You can take a look at this web page. It contains the whole SAD 1.18 content. The pdf is more than 16 MB, whereas this html page is only 6MB. Note that […]
We almost finished implementing a long-standing feature request,
introducing MVC / MVVM for Web Applications (like RubyOnRails) in mORMot.
This is a huge step forward, opening new perspectives not only to our framework, but for the Delphi community.
In respect to the existing MVC frameworks for Delphi, our solution is closer to Delphi On Rails (by the convention-over-configuration pattern) than the Delphi MVC Framework or XMM.
The mORMot point of view is unique, and quite powerful, since it is integrated with other parts of our framework, as its ORM/ODM or interface-based services.
Of course, this is a work in progress, so you are welcome to put your feedback, patches or new features!
We will now explain how to build a MVC/MVVM web application using
mORMot, starting from the "30
- MVC Server" sample.
First of all, check the source in our GitHub repository: two
.pas files, and
a set of minimalist Mustache
This little web application publishes a simple BLOG, not fully finished yet
(this is a Sample, remember!).
But you can still execute it in your desktop browser, or any mobile device (thanks to a simple Bootstrap-based responsive design), and see the articles list, view one article and its comments, view the author information, log in and out.
This sample is implemented as such:
||Mustache template engine in the Views sub-folder|
||Defined as one
For the sake of the simplicity, the sample will create some fake data in its own local SQlite3 database, the first time it is executed.
2014-10-08. Synopse Company
Just a small message to let you know that I was invited, as a speaker to the BE Delphi 2014 event. This year, the sessions will focus on n-Tier development, so our little mORMot does make sense in the landscape! If you are in Belgium or in Europe, we would be very pleased to meet you there! Thanks […]
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.
The first listed application - EasyMail7 Client-Server Email Marketing Solution - is indeed impressive, and shows well the Client-Server and storage abilities of the framework.
You certainly noticed that WebSocket is the current
trendy flavor for any modern web framework.
But does it scale? Would it replace HTTP/REST?
There is a feature request ticket about them for mORMot, so here are some thoughts - matter of debate, of course!
I started all this by answering a StackOverflow question, in which the actual answers were not accurate enough, to my opinion.
From my point of view, Websocket - as a protocol - is some kind of monster.
You start a HTTP stateless connection, then switch to WebSocket
mode which releases the TCP/IP dual-direction layer, then you may switch later
on back to HTTP...
It reminds me some kind of monstrosity, just like encapsulating everything over HTTP, using XML messages... Just to bypass the security barriers... Just breaking the OSI layered ...
It reminds me the fact that our mobile phone data providers do not use broadcasting for streaming audio and video, but regular Internet HTTP servers, so the mobile phone data bandwidth is just wasted when a sport event occurs: every single smart phone has its own connection to the server, and the same video is transmitted in parallel, saturating the single communication channel... Smart phones are not so smart, aren't they?
WebSocket sounds like a clever way to circumvent a
But why not use a dedicated layer?
I hope HTTP 2.0 would allow pushing information from the server, as part of the standard... and in one decade, we probably will see WebSocket as a deprecated technology.
You have been warned. Do not invest too much in WebSockets..
OK. Back to our existential questions...
First of all, does the WebSocket protocol scale?
Today, any modern single server is able to server millions of clients at once.
Its HTTP server software has just to be is Event-Driven (IOCP) oriented (we are not in the old Apache's one connection = one thread/process equation any more).
Even the HTTP server built in Windows (http.sys - which is used in mORMot) is IOCP oriented and very efficient (running in kernel mode).
From this point of view, there won't be a lot of difference at scaling between WebSocket and a regular HTTP connection. One TCP/IP connection uses a little resource (much less than a thread), and modern OS are optimized for handling a lot of concurrent connections: WebSocket and HTTP are just OSI 7 application layer protocols, inheriting from this TCP/IP specifications.
But, from experiment, I've seen two main problems with WebSocket:
- It does not support CDN;
- It has potential security issues.
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
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);
- FreePascal Compiler 2.7.1;
- Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).
This series of articles will introduce you to mORMot's Cross-Platform abilities:
- Units and platforms;
- Generating the client code wrappers;
- Delphi / FreePascal clients;
- Smart Mobile Studio clients.
Any feedback is welcome in our forum, as usual!