You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2011-08-07 08:05:08
SQLite3-powered, not SQLite3-limited
The core database of this 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 is included, and can be used instead or together with the SQLite3 engine. Since revision 1.15 of the framework you may be able to access any remote database, and use one or more OleDB (or 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.
Since revision 1.15, our ORM RESTful framework is able to access any available database engine, via a set of generic units and classes.
The framework still relies on SQLite3 as its SQL core on the server, but a dedicated mechanism allows access to any remote database, and mix those tables content with the native ORM tables of the framework. Thanks to the unique Virtual Tables mechanism of SQLite3, those external tables may be accessed as native SQLite3 tables in our SQL statements.
The current list of available external database classes is:
- Any OleDB provider;
- Oracle direct access (via OCI);
- A SQLite3 database file.
This list is not closed, and may be completed in the near future. Any help is welcome here: it's not difficult to implement a new unit, following the patterns already existing. You may start from an existing driver (e.g. Zeos or Alcinoe libraries). Open Source contribution are always welcome!
In fact, OleDB is a good candidate for database access with good performance, Unicode native, with a lot of available providers. Thanks to OleDB, we are already able to access to almost any existing database. The code overhead in the server executable will also be much less than with adding any other third-party Delphi library. And we will let Microsoft or the OleDB provider perform all the testing and debugging for each driver.
An Oracle dedicated direct access was added, because all available OleDB providers for Oracle (i.e. both Microsoft's and Oracle's) do have problems with handling BLOB, and we wanted our Clients to have a light-weight access to this great database.
Thanks to the design of our classes, it was very easy (and convenient) to implement SQLite3 direct access. It's even used for our regression tests, in order to implement stand-alone unitary testing.
The SAD documents contains also some new diagrams, which will help understand how the Client-Server ORM architecture works.
Offline
#2 2011-08-11 08:17:01
Re: SQLite3-powered, not SQLite3-limited
Offline
#3 2012-07-24 11:55:44
Re: SQLite3-powered, not SQLite3-limited
Note: 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.
TSQLRecordExternal class type has been removed, to allow any TSQLRecord (e.g. TSQLRecordMany) to be used with VirtualTableExternalRegister() - there was indeed no implementation requirement to force a specific class type.
It will allow to use internal or external database just by running VirtualTableExternalRegister (or not), before server initialization. Business logic code will therefore be abstracted from the database engine processing the data.
It may be used for instance to allow custom database configuration at runtime, depending on the customer's expectations (or license).
Offline
Pages: 1