Almost every time I'm debugging some core part of our framework, I like to see the generated asm, and trying to optimize the pascal code for better speed - when it is worth it, of course! I just made a nice observation, when comparing the assembler generated by Delphi to FPC's output. Imagine you […]
2015-06-21. Pascal Programming
One common problem when handling dates and times, is that time is shown and entered as local, whereas the computer should better use non-geographic information - especially on a Client-Server architecture, where both ends may not be on the same physical region.
A time zone is a region that observes a uniform standard time for
legal, commercial, and social purposes.
Time zones tend to follow the boundaries of countries and their subdivisions because it is convenient for areas in close commercial or other communication to keep the same time.
Most of the time zones on land are offset from Coordinated Universal Time (UTC) by a whole number of hours, or minutes.
Even worse, some countries use daylight saving time for part of the year, typically by changing clocks by an hour, twice every year.
The main rule is that any date and time stored should be stored in
UTC, or with an explicit Zone identifier (i.e. an explicit offset to
the UTC value).
Our framework expects this behavior: every date/time value stored and handled by the ORM, SOA, or any other part of it, is expected to be UTC-encoded.
At presentation layer (e.g. the User Interface), conversion to/from local times should take place, so that the end-user is provided with friendly clock-wall compatible timing.
As you may guess, handling time zones is a complex task, which should be
managed by the Operating System itself.
Since this cultural material is constantly involving, it is updated as part of the OS.
In practice, current local time could be converted from UTC from the current system-wide time zone. One of the only parameters you have to set when installing an Operating System is to pickup the keyboard layout... and the current time zone to be used. But in a client-server environment, you may have to manage several time zones on the server side: so you can't rely on this global setting.
One sad - but predictable - news is that there is no common way of encoding
time zone information.
Under Windows, the registry contains a list of time zones, and the associated time bias data. Most POSIX systems (including Linux and Mac OSX) do rely on the IANA database, also called
tzdata - you may
have noticed that this particular package is often updated with your
Both zone identifiers do not map, so our framework needed something to be shared on all systems.
2015-06-06. Pascal Programming
I'm confused by the GetIt Submitting official blog page. Reminds me the darker ages of Delphi licensing change of XE3. GetIt is the new XE8 package manager for RAD Studio. Information about how to submit your libraries to GetIt has just been made available by Embarcadero. The idea behind GetIt is […]
One year ago, we published a set of slides about the main concepts implemented by our framework. Mainly about ORM (and ODM), NoSQL, JSON, SOA, MVC (and MVVM), SOLID, DDD, CQRS and some patterns like Stubs, Mocks, Factory, Repository, Unit-Of-Work. Worth a look, if you want to find out the benefits […]
2015-05-24. Pascal Programming
Did you notice the new https://www.beginend.net web site, by Eric Grange? It is a blog feeds aggregator web site, dedicated to Delphi! It features: a maintained list of websites (including our very little blog); fast to load - thanks to good use of CDN; is not polluted by ads; nor breaking the links […]
We introduced DDD concepts some time ago, in a series of articles in this blog. At that time, we proposed a simple way of using mORMot types to implement DDD in your applications. But all Domain Entitities being tied to the framework TSQLRecord class did appear as a limitation, breaking the […]
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 […]
2015-05-08. Pascal Programming
There was some discussion about the new
TStringHelper feature introduced in latest versions of
I was told to be some kind of archaic guy, not able to see the benefit of this.
Reducing opinions to a conservative/progressive approach - another famous 10 kinds of coders - is very reductive.
Of course, this was IMHO unfair and my point was that I have the feeling
that some decisions about the Delphi language and RTL are inadequate.
Some changes are welcome. I enjoy the introduction of generics - even if it is was painful, and even buggy (do not use TList<T> with managed record types in XE8!).
But some upcoming changes about the
string policy - breaking
everything just because we want to align with mainstream C# or Java habits -
are just non sense to me.
I really think that Embarcadero deciders like to shoot their own foot.
Or - certainly worse - our own feet!
I will post here some part of the discussion...
So that we may be able to share our ideas.
2015-05-03. Pascal Programming
I've just updated the documentation part about the SOLID Design
The former blog article (almost 4 years old!) sounds like a bit deprecated now...
This is why I would extract here an updated version of this material.
Ensure you checked the corresponding part of the mORMot documentation, which is the updated reference, and probably the easiest to read - including links to all the other documentation.
The acronym SOLID is derived from the following OOP principles (quoted from the corresponding Wikipedia article):
- Single responsibility principle: the notion that an object should have only a single responsibility;
- Open/closed principle: the notion that "software entities ... should be open for extension, but closed for modification";
- Liskov substitution principle: the notion that "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” - also named as "design by contract";
- Interface segregation principle: the notion that "many client specific interfaces are better than one general purpose interface.";
- Dependency inversion principle: the notion that one should "Depend upon Abstractions. Do not depend upon concretions.". Dependency injection is one method of following this principle, which is also called Inversion Of Control (aka IoC).
If you have some programming skills, those principles are general statements you may already found out by yourself. If you start doing serious object-oriented coding, those principles are best-practice guidelines you would gain following.
They certainly help to fight the three main code weaknesses:
- Rigidity: Hard to change something because every change affects too many other parts of the system;
- Fragility: When you make a change, unexpected parts of the system break;
- Immobility: Hard to reuse in another application because it cannot be disentangled from the current application.
2015-04-20. Pascal Programming
It is worth saying again.
I'm not speaking this time about performance issues, but about a common misunderstanding of what the latest version of Delphi offers.
Since Delphi "NextGen"
compilers did break the memory model (introducing
ARC), and also reducing low-level types (e.g. RawByteString/AnsiString),
we can not say that Delphi is a single cross-compiler.
In practice, it has a set of cross-compilers.
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.
When publishing SOA services, most of them are defined as
stateless, in a typical query/answer pattern - see
Service-Oriented Architecture (SOA).
This fits exactly with the RESTful approach of Client-Server services via interfaces, as proposed by the framework.
But it may happen that a client application (or service) needs to know the state of a given service. In a pure stateless implementation, it will have to query the server for any state change, i.e. for any pending notification - this is called polling.
Polling may take place for instance:
- When a time consuming work is to be processed on the server side. In this case, the client could not wait for it to be finished, without raising a timeout on the HTTP connection: as a workaround, the client may start the work, then ask for its progress status regularly using a timer and a dedicated method call;
- When an unpredictable event is to be notified from the server side. In this case, the client should ask regularly (using a timer, e.g. every second), for any pending event, then react on purpose.
It may therefore sounds preferred, and in some case necessary, to have the ability to let the server notify one or several clients without any prior query, nor having the requirement of a client-side timer:
- Polling may be pretty resource consuming on both client and server sides, and add some unwanted latency;
- If immediate notification is needed, some kind of "long polling" algorithm may take place, i.e. the server will wait for a long time before returning the notification state if no event did happen: in this case, a dedicated connection is required, in addition to the REST one;
- In an event-driven systems, a lot of messages are sent to the clients: a proper publish/subscribe mechanism is preferred, otherwise the complexity of polling methods may increase and become inefficient and unmaintainable;
- Explicit push notifications may be necessary, e.g. when a lot of potential events, associated with a complex set of parameters, are likely to be sent by the client.
Our mORMot framework is therefore able to easily implement
asynchronous callbacks over WebSockets,
defining the callbacks as
interface parameters in service method
definitions - see
Available types for methods parameters.
In a previous
article, we presented how Master/Slave replication may be easily
implemented in mORMot's RESTful ORM.
Do not forget to visit the corresponding paragraphs of our online documentation, which has been updated, and is more accurate!
Sometimes, the on-demand synchronization is not enough.
So we have just introduced real-time replication via WebSockets.
For instance, you may need to:
- Synchronize a short list of always evolving items which should be reflected as soon as possible;
- Involve some kind of ACID-like behavior (e.g. handle money!) in your replicated data;
- Replicate not from a GUI application, but from a service, so use of a
TTimeris not an option;
- Combine REST requests (for ORM or services) and master/slave ORM replication on the same wire, e.g. in a multi-threaded application.
In this case, the framework is able to use WebSockets and
asynchronous callbacks to let the master/slave replication - see
Asynchronous callbacks - take place without the need to ask explicitly
for pending data.
You would need to use
TSQLRestServer.RecordVersionSynchronizeSlaveStop methods over the
proper kind of bidirectional connection.
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.
2015-03-30. Open Source
Perhaps it is due to a lot of projects moving from closing Google Code to GitHub, but I experimented some GitHub random communication errors since last week.
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 […]
Just to share a commit of some interest to FPC/Lazarus users. Ondrej Pokorny (aka "reddwarf" in our forums) did send to us a nice implementation of our SynTaskDialog.pas unit, compatible with Lazarus. Since it is incompatible with the current state of the other mORMot UI units (which are […]
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% !!! […]
We have just included some optimized x64 assembler to our Open
Source SynCrypto.pas unit
so that SHA-256 hashing will perform at best speed.
It is an adaptation from tuned Intel's assembly macros, which makes use of the SSE4 instruction set, if available.
2015-02-16. Open Source
And in fact, it is fast, and sounds pretty great!
Here are some numbers, compared with SuperObject, standard DBXJson, dwsJSON, QDAC and mORMot.
Please refer to previous benchmark articles about those libraries. We will now focus on JsonDataObjects.