Synopse Open Source

2014-11-14

Automatic TSQLRecord memory handling

By AB4327-GANDI, 2014-11-14. Open Source › mORMot Framework

Working with objects is pretty powerful, but requires to handle manually the created instances life time, via try .. finally 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 TSQLRecord level:

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

2014-11-05

mORMot documentation as web

By AB4327-GANDI, 2014-11-05. Open Source › mORMot Framework

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 […]

2014-10-25

Are "Micro Services" the proper way of writing SOA?

By AB4327-GANDI, 2014-10-25. Open Source › mORMot Framework

I just wanted to share a great article by Martin Fowler, about Micro Services. IMHO such "Micro Services" are the proper way of defining a SOA project, following SOLID principles. If we follow the "Single Responsibility" principle, we will define small uncoupled services, which […]

2014-10-24

MVC/MVVM Web Applications

By AB4327-GANDI, 2014-10-24. Open Source › mORMot Framework

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 views.

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:

MVVM	Source	mORMot
Model	`MVCModel.pas`	`TSQLRestServerDB` ORM over a SQlite3 database
View	`*.html`	Mustache template engine in the Views sub-folder
ViewModel	`MVCViewModel.pas`	Defined as one `IBlogApplication` interface

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

Meet in Belgium!

By AB4327-GANDI, 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 […]

2014-09-13

Some thoughts about "modern" pascal, generics, code and data structures

By AB4327-GANDI, 2014-09-13. Pascal Programming

In a comment of a Google+ announcement about new C# features, Stephan did react about my naive enthusiasm about SmartPascal.

Apart from the fact that he did miss the numerous ways of creating Windows executable in this dialect (I quoted at least 5 diverse ways), he was chocked by the fact that the SmartPascal syntax, in its actual idiom, does not support generics.

But are generics mandatory?
I'm not speaking about any drug identified by its chemical name rather than its brand name (Wikipedia).
I would neither comment on the current Delphi implementation of generics (which may appear not so polished, nor very widely used, even in the Delphi RTL/FMX, but for TList<T> TDictionary<>).
Just share some thoughts about what is, to my opinion - which may be wrong and biased! - the most important part of today's programming.

2014-09-12

Faster WideString process for good old non Unicode Delphi 6-2007

By AB4327-GANDI, 2014-09-12. Open Source › Open Source libraries

For pre-Unicode versions of Delphi, the unique way of having UTF-16 native type is to use the WideString type.
This type, under Windows, matched the BSTR managed type, as used by OLE and COM components.

In Delphi, WideString implementation calls directly the corresponding Windows API, and do not use the main Delphi heap manager.
Even if since Vista, this API did have a huge speed-up, it is still in practice much slower than the regular string type. Problems is not about UTF-16 encoding, but about the memory allocation, which is shared among processes, using the Windows global heap, and is much slower than our beloved FastMM4.
Newer versions of Delphi (since Delphi 2009) feature a refactored string = UnicodeString type, which relies on FastMM4 and not the Windows API, and is much faster than WideString.

Within our mORMot framework, we by-passed this limitation by using our RawUTF8 type, which is UTF-8 encoded, so as Unicode ready as the new UnicodeString type, and pretty fast.
In a recent internal project, we had to use a lot of WideString instances, to support UTF-16 encoding in Delphi 7/2007, involving a lot of text.

It sounded to be very slow, so we had to do something!

This is where our new SynFastWideString unit comes in.

Purpose of this unit is to patch the system.pas unit for older versions of Delphi, so that WideString memory allocation would use FastMM4 instead of the slow BSTR Windows API.
It will speed up the WideString process a lot, especially when a lot of content is allocated, since FastMM4 is much more aggressive than Windows' global heap and the BSTR slow API. It could be more than 50 times faster, especially when releasing the used memory.
The WideString implementation pattern does NOT feature Copy-On-Write, so is still slower than the string UnicodeString type as implemented since Delphi 2009. This is the reason why this unit won't do anything on Unicode versions of the compiler, since the new string type is to be preferred there.

Legacy code, mORMot, and database sharing

By AB4327-GANDI, 2014-09-12. Open Source › mORMot Framework

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.

For instance, you would like to use mORMot for new features, and/or add mobile or HTML clients - see Cross-Platform clients.
In this case, the ORM advanced features - like ORM Cache or BATCH process, see BATCH sequences for adding/updating/deleting records - may conflict with the legacy code, for the tables which may have to be shared.
Here are some guidelines when working on such a project.

To be exhaustive about your question, we need to consider each ORM CRUD operation.
We may have to divide them in three kinds: read queries, insertions, and modifications of existing data.