Synopse

To content | To menu | To search

Tag - Documentation

Entries feed

2013, Monday March 25

SynProject tool 1.18

We have uploaded an updatetd compiled version of our Open Source SynProject tool in SynProject.zip.

Synopse SynProject is an open source application for code source versioning and automated documentation of software projects.
Licensed under a GPL license.

Main feature is a new (better-looking?) template for the generated files.
See our mORMot framework documentation for a good sample of rendering content.

The internal wiki pages related to this tool has also been refreshed.

Feedback is welcome on our forum!

2013, Sunday February 17

Interface-based service sample: remote SQL access

You will find in the SQLite3\Sample\16 - Execute SQL via services folder of mORMot source code a Client-Server sample able to access any external database via JSON and HTTP.
It is a good demonstration of how to use an interface-based service between a client and a server.
It will also show how our SynDB classes have a quite abstract design, and are easy to work with, whatever database provider you need to use.

The corresponding service contract has been defined:

  TRemoteSQLEngine = (rseOleDB, rseODBC, rseOracle, rseSQlite3, rseJet, rseMSSQL);

IRemoteSQL = interface(IInvokable) ['{9A60C8ED-CEB2-4E09-87D4-4A16F496E5FE}'] procedure Connect(aEngine: TRemoteSQLEngine; const aServerName, aDatabaseName, aUserID, aPassWord: RawUTF8); function GetTableNames: TRawUTF8DynArray; function Execute(const aSQL: RawUTF8; aExpectResults, aExpanded: Boolean): RawJSON; end;

Purpose of this service is:
- To Connect() to external databases, given the parameters of a standard TSQLDBConnectionProperties. Create() constructor;
- Retrieve all table names of this external database as a list;
- Execute any SQL statement, returning the content as JSON array, ready to be consumed by AJAX applications (if aExpanded is true), or a Delphi client (e.g. via a TSQLTableJSON and the mORMotUI unit).

Of course, this service will be define as sicClientDriven mode, that is, the framework will be able to manage a client-driven TSQLDBProperties instance life time.

Benefit of this service is that no database connection is required on the client side: a regular HTTP connection is enough.
No need to install nor configure any database provider, and full SQL access to the remote databases.

Due to our optimized JSON serialization, it will probably be faster to work with such plain HTTP / JSON services, instead of a database connection through a VPN. In fact, database connections are made to work on a local network, and do not like high-latency connections, which are typical on the Internet.

Continue reading...

2013, Sunday January 27

Video about mORMot authentication

A new mORMot user notified on our forum that he just made a short video, about authentication and security with our framework, from the perspective of an AJAX Client.
Many thanks for sharing your experiences!

This video illustrate how RESTful authentication is implemented by mORMot.
It compares also with the unsecured scheme used with DataSnap - pretty informative.

Click here to watch the 5 minutes video.

Each time you are logged, a light session is created on the server, and is the root of all mORMot advanced security attributes.
Also a big difference with the heavy implementation of DataSnap session handling.

Note that the 1.18 upcoming revision feature Windows Authentication, i.e. automatic log with your Windows credentials.
With it, it is not even necessary to enter/remember/manage your login/password pair: mORMot is able to use your Windows domain security to let you connected.

Feedback is welcome on our forum.

2013, Saturday January 5

Domain-Driven-Design and mORMot

Implementing Domain-Driven-Design (DDD) is one goal of our mORMot framework.

We already presented this particular n-Tier architecture.

It is now time to enter deeper into the material, provide some definition and reference.
You can also search the web for reference, or look at the official web site.
A general presentation of the corresponding concepts, in the .NET world, was used as reference of this blog entry.

Stay tuned, and ride the mORMot!

Continue reading...

2012, Wednesday December 5

DataSnap-like Client-Server JSON RESTful Services in Delphi 6-XE3

Article update:
The server side call back signature changed since this article was first published in 2010. Please refer to the documentation or this forum article and associated commit.
The article was totally rewritten to reflect the enhancements.
And do not forget to see mORMot's interface-based services!

You certainly knows about the new DataSnap Client-Server features, based on JSON, introduced in Delphi 2010.
http://docwiki.embarcadero.com/RADStudi … plications

We added such communication in our mORmot Framework, in a KISS (i.e. simple) way: no expert, no new unit or new class. Just add a published method Server-side, then use easy functions about JSON or URL-parameters to get the request encoded and decoded as expected, on Client-side.

Continue reading...

2012, Wednesday November 28

Breaking change in mORmot: SQLite3*.pas units renamed mORMot*.pas

All former SQLite3\SQLite3*.pas units have been renamed to SQLite3\mORMot*.pas to match the database-agnostic scheme of the mORMot framework.

This is a major break change, so all your "uses" clauses in your code is to be change to follow the new naming.

See this commit, which includes documentation.
During the same winter cleaning, we get rid of the deprecated Zeos directory in our source code repository.

Now we are very close to the 1.18 release!
Don't hesitate to report any bug/issue/limitation as soon as possible!

Feedback is welcome on our forum.

2012, Monday September 10

Don't be confused by our little mORMot !

We got some interesting feedback in reddit.

I looked at your website and it is a bit confusing to be honest. After browsing for five minutes I still can't figure out what it is that this framework is supposed to do. It seems like a strange mish mash of different unrelated libraries. You've got some client-server stuff. Some SQLite stuff, which doesn't really fit with client server stuff as it is not a server database. Then there is some PDF stuff.
What is the big picture? What does this actually do?

Such confusion does make sense. Our web site is split into forum, blog, source-code repository and tickets, some wiki pages.

Here are some points of orientation.

Continue reading...

2012, Sunday September 9

Synopse mORMot framework 1.17

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

The main new features are the following:

We have some very exciting features on the road-map for the next 1.18 release, like direct Event/CallBacks handling.
Stay tuned!

Continue reading...

2012, Wednesday July 25

Synopse mORMot benchmark

After having tested and enhanced the external database speed (including BATCH mode), we are now able to benchmark all database engines available in mORMot.

In fact, the ORM part of our framework has several potential database backends, in addition to the default SQLite3 file-based engine.
Each engine may have its own purpose, according to the application expectation.

The following tables try to sum up all available possibilities, and give some benchmark (average rows/seconds for writing or read). 

In these tables:

  • 'internal' means use of the internal SQLite3 engine;
  • 'external' stands for an external access via SynDB;
  • 'TObjectList' indicates a TSQLRestServerStaticInMemory instance either static (with no SQL support) or virtual (i.e. SQL featured via SQLite3 virtual table mechanism) which may persist the data on disk as JSON or compressed binary;
  • 'trans' stands for Transaction, i.e. when the write process is nested within BeginTransaction / Commit calls;
  • 'batch' mode will be described in this article;
  • 'read one' states that one object is read per call (ORM generates a SELECT * FROM table WHERE ID=?);
  • 'read all' is when all 5000 objects are read in a single call (i.e. running SELECT * FROM table);
  • ACID is an acronym for "Atomicity Consistency Isolation Durability" properties, which guarantee that database transactions are processed reliably: for instance, in case of a power loss or hardware failure, the data will be saved on disk in a consistent way, with no potential loss of data.
In short: depending on the database you can persist up to 150,000 objects per second, or retrieve  240,000 objects per second.
With a high-performance database like Oracle and our direct access classes, you write 53,000 and read 72,000 objects per second.
Difficult to find a faster ORM, I suspect. :)

Continue reading...

2012, Tuesday July 24

SQLite3-powered, not SQLite3-limited

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

The core database of our mORMot 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 (TObjectList-based) is included, and can be used instead or together with the SQLite3 engine.
Or you may be able to access any remote database, and use one or more OleDB, ODBC, ZDBCTDataSet, (or direct 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.

(article updated after removal of the TSQLRecordExternal class type for revision 1.17 - note also that BATCH process is now directly supported by the framework and converted to bound array parameters if available)

Continue reading...

2012, Sunday June 24

Use TDataSet in mORMot or SynDB

In our documentation, and in all our code source, we avoid using the VCL DB.pas related units, and all the associated RAD components.

This is by design, since our experiment encouraged us to "think ORM, forget anything about RAD (and even SQL in most cases)" in mORMot.
And it introduced some nice border-side effect to Delphi users, e.g. that even a "Delphi Starter Edition" is able to use mORMot, have access to SQLite3, MS SQL or Oracle or any other DB, add interface-based RESTful JSON services over it, just for free...

But in the real world, you may need to upgrade some existing application, get rid of the BDE, or add a SOA layer over an existing business intelligence.
And mORMot is able to serve you well in those scenarios.
That's why we just added a first attempt to expose SynDB results and mORMOt TSQLTableJSON content into a TDataSet.

Continue reading...

2012, Monday May 28

Synopse mORMot Framework 1.16

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

The main new features are the following:

Thanks to its features, mORMot is now able to provide a stand-alone Domain-Driven Design framework for Delphi.

Quite a long and nice road for a little mORMot, and more to come!

Continue reading...

2012, Friday May 25

Domain-Driven design

With a previous article, we introduced the concept of "Domain-Driven design" into our framework presentation.

It's now time to detail a bit more this very nice software architecture design, and how mORMot is able to achieve such an implementation pattern.

Continue reading...

2012, Wednesday April 25

The mORMot attitude

In a discussion with Henrick Hellström, in Embarcadero forums, I wrote some high-level information about mORMot.

It was clear to me that our little mORMot is now far away from a simple Client-Server solution.

The Henrick point was that with Real Thin Client (RTC), you are able to write any Client-Server solution, even a RESTful / JSON based one.

He is of course right, but it made clear to me all the work done in mORMot since its beginning.
From a Client-Server ORM, it is now a complete SOA framework, ready to serve Domain-Driven-Design solutions.

Continue reading...

2012, Friday April 13

Custom JSON serialization of any class

By default, our mORMot framework is able to serialize any class into a true JSON object.

All published properties will be written as JSON object members.

In some cases, it may be handy to have a custom serialization, for instance if you want to manage some third-party classes, or to adapt the serialization scheme to a particular purpose, at runtime.

Continue reading...

2012, Wednesday March 28

Return custom content from an interface-based service

As stated by this previous article, the default answer format is a valid JSON object.

In some cases, it may be useful to have a service operation (i.e. an interface method) returning any content, e.g. some plain TEXT, HTML or binary data (like a picture).

Continue reading...

2012, Wednesday March 7

Interface based services - sample code

In addition to the other related blog articles, you can find in the "SQLite3/Samples/14 - Interface based services" folder of the supplied source code distribution, a dedicated sample about this feature.

Purpose of this code is to show how to create a client-server service, using interfaces, over named pipe communication.

Continue reading...

Interface based services - Implementation details

You will find out in SQLite3Commons.pas all classes implementing this interface communication.

There are two levels of implementation:
- A services catalog, available in TSQLRest.Services property, declared as TServiceContainer (with two inherited versions, for each side);
- A service factory for each interface, declared as TServiceFactory (also with two inherited versions, for each side).

In fact, TServiceFactory.Create constructor will retrieve all needed RTTI information of the given interface, i.e. GUID, name and all methods (with their arguments). It will compute the low-level stack memory layout needed at execution. And the corresponding "contract" will be computed, to validate that both client and server expect the exact same interface.

On the server side, TServiceFactoryServer.ExecuteMethod method (and then a nested TServiceMethod.InternalExecute call) is used to prepare a valid call to the implementation class code from a remote JSON request.

On the client side, a TInterfacedObjectFake class will be created, and will emulate a regular Delphi interface call using some on-the-fly asm code generated in the TServiceFactoryClient.Create constructor.

Continue reading...

Interface based services - Using services on the Client or Server sides

Once the service is registered on the server side, it is very easy to use it in your code.

In a complex Service Oriented Architecture, it is pretty common to have services calling each other. Code re-usability is a key here. So you'll have to consume services on the server side. According to the SOLID design principles, you'd better rely on abstraction in your code, i.e. not call the service implementation, but the service abstract interface.

You can use the following method of your TSQLRest.Services instance (note that this method is available on both client and server sides, so is the right access point to all services):

 function TServiceFactory.Get(out Obj): Boolean;

Continue reading...

Interface based services - Server side

In order to have an operating service, you'll need to implement a Delphi class which matches the expected interface.

Continue reading...

- page 1 of 2