Synopse Open Source

Our framework features an integrated logging class, ready to be enabled for support and statistics.

For debugging purposes, it could be very handy to output the logging content to a console window.
It enables interactive debugging of a Client-Server process, for instance: you can interact with the Client, then look in real time at the server console window, and inspect which requests are processed, without the need to open the log file.

Depending on the events, colors will be used to write the corresponding information. Errors will be displayed as light red, for instance.

Our Open Source mORMot framework is now available in revision 1.16.

The main new features are the following:

• Interface-based services, i.e. comparable to WCF, but with Delphi strengths;
• ORM cache which purpose is to enhance server scaling and client responsiveness;
• Automatic JOIN query to unleash the underneath DB power;
• SQLite3 engine updated to latest revision 3.7.12.1;
• Major update of the associated documentation (now more than 800 pages);
• A lot of bug fixes and enhancements, mainly from users requests - thanks you all for your feedback, patches and ideas!

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.

In order to let our TSynLog logging class intercept all exceptions, we use the low-level global RtlUnwindProc pointer, defined in System.pas.

Alas, under Delphi 5, this global RtlUnwindProc variable is not existing. The code calls directly the RtlUnWind Windows API function, with no hope of custom interception.

Two solutions could be envisaged:

• Modify the Sytem.pas source code, adding the new RtlUnwindProc variable, just like Delphi 7; 
• Patch the assembler code, directly in the process memory.

The first solution is simple. Even if compiling System.pas is a bit more difficult than compiling other units, we already made that for our Enhanced RTL units. But you'll have to change the whole build chain in order to use your custom System.dcu instead of the default one. And some third-party units (only available in .dcu form) may not like the fast that the System.pas interface changed...

So we used the second solution: change the assembler code in the running process memory, to let call our RtlUnwindProc variable instead of the Windows API.

The SQlite3 engine has ability to create Virtual Tables from code. From the perspective of an SQL statement, the virtual table object looks like any other table or view. But behind the scenes, queries from and updates to a virtual table invoke callback methods on the virtual table object instead of reading and writing to the database file.

The virtual table mechanism allows an application to publish interfaces that are accessible from SQL statements as if they were tables. SQL statements can in general do anything to a virtual table that they can do to a real table, with the following exceptions:
- One cannot create a trigger on a virtual table.
- One cannot create additional indices on a virtual table. (Virtual tables can have indices but that must be built into the virtual table implementation. Indices cannot be added separately using CREATE INDEX statements.)
- One cannot run ALTER TABLE ... ADD COLUMN commands against a virtual table.
- Particular virtual table implementations might impose additional constraints. For example, some virtual implementations might provide read-only tables. Or some virtual table implementations might allow INSERT or DELETE but not UPDATE. Or some virtual table implementations might limit the kinds of UPDATEs that can be made.

Example of virtual tables, already included in the SQLite3 engine, are FTS or RTREE tables. A custom virtual table might represent in-memory data structures (like TSQLVirtualTableJSON, TSQLVirtualTableBinary). Or it might represent a view of data on disk that is not in the SQLite3 format (e.g. TSQLVirtualTableLog). Or the application might compute the content of the virtual table on demand.

Thanks to the generic implementation of Virtual Table in SQLite3, you can use such tables in your SQL statement, and even safely execute a SELECT statement with JOIN or custom functions, mixing normal SQLite3 tables and any other Virtual Table.

A dedicated mechanism has been added to the framework, beginning with revision 1.13, in order to easily add such virtual tables with pure Delphi code, just by inheriting some classes.