You are not logged in.
- Topics: Active | Unanswered
#1 2010-10-29 14:02:30
Close future of the framework: database agnosticism
I'm prototyping running our framework using Zeos (more precisely the ZDBC layer, not the component-oriented part) to connect to other DMBS engine.
You'll have three database systems available:
- static fast in-memory database, using TSQLRestServerStatic;
- embedded SQLite3 engine, using the SQLite3 unit and its classes;
- Zeos/ZDBC engine, for remotely direct access to a lot of database engines.
Zeos supports direct connectivity to the following databases using the vendor provided, native interface (list dated from 2008, newer list is welcome):
* MySQL 3.20 - 5.0
* PostgreSQL 6.5 - 8.1
* Firebird 1.0 - 2.0
* Interbase 5.0 - 7.5
* Microsoft SQL Server 7, 2000
* Sybase ASE 12.0, 12.5
* Oracle 9i
* SQLite 2.8, 3.6
For other databases, Zeos is able to use an Active Data Objects (ADO) Bridge.
We'll be integrating the 7.0 version of the library, because we want it to be compatible from Delphi 6 up to Delphi XE.
The only missing part is the CREATE TABLE particularities. Not too difficult to guess. But it's strange that the JDBC standard (on which ZDBC is based) doesn't have any direct handling of table creation. In an ORM, table creation is a need.
Most other parts are already handled by Zeos. Calling the ZDBC API will do most of the work.
So we'll have to change the name of our framework. "Synopse SQLite3 framework" won't make it any more.
What do you think about "Synopse ORM" or "SynORM" ?
Offline
#2 2010-11-01 16:05:21
- WladiD
- Member
- From: Germany
- Registered: 2010-10-27
- Posts: 40
Re: Close future of the framework: database agnosticism
Synopse ORgyM (Overview of an orgy in gym ORM)
Just fun, but very distinctive.
Offline
#4 2010-11-01 19:47:16
Re: Close future of the framework: database agnosticism
I'm sure that with such a name, we'll have some Internet traffic!!!!
One another distinctive feature of the framework is that it will be able to select multiple database layers for the same project.
For instance, you could be able to store some data in an Oracle database, but rely on a SQLite3 engine for configuration storage, and on our TSQLRestStatic server to store in-memory tables (like a TList mapped into the ORM).
I've another idea: add a dedicated database engine, dedicated to audit trail of huge data. Some kind of mostly read-only table, which will be stored and accessed in a memory mapped file.
I've seen Oracle (or such) databases filled with such login/audit trail data.... whereas a dedicated file using memory-mapping and direct binary encoding will be much greater!
Offline
#5 2010-11-02 15:44:23
Re: Close future of the framework: database agnosticism
I'm into naming it MORMOT.
This could be an acronym for "Manage Object Relational Mapping Over Territory"...
So that you can enjoy your classes and business model territory, then hibernate in your database/burrow on purpose.
What do you think about that?
I've registered http://mormot.net
And I like Marmots/Mormots very very very much.
Nice animals!
I would like to write it mORMmot
Trying for drawing some logo... but I'm no artist!
Offline
#7 2010-11-20 19:02:16
Re: Close future of the framework: database agnosticism
I just posted this on ZeosLib official forum:
I've successfully written some database related units, working for Delphi 6 up to XE. The key is to use a "proprietary" type internally, using UTF8, then provide dedicated conversion when you want to interact with the VCL (i.e. the string type, depending on the Delphi version it was compiled with).
Our SQLite3 Framework has 100% UNICODE compatibility, that is compilation under Delphi 2009/2010/XE. The code has been deeply rewritten and tested, in order to provide compatibility with the String=UnicodeString paradigm of these compilers.
Since our SQLite3 framework is natively UTF-8 (this is the better character encoding for fast text - JSON - streaming/parsing and it is natively supported by the SQLite3 engine), we had to fix the way our framework used strings, in order to handle all versions of Delphi (even pre-Unicode versions, especially the Delphi 7 version we like so much), and provide compatibility with the Free Pascal Compiler.
Some string types have been defined, and used in the code for best cross-compiler efficiency (avoiding most conversion between formats):
- RawUTF8 is used for every internal data usage, since both SQLite3 and JSON do expect UTF-8 encoding;
- WinAnsiString where WinAnsi-encoded AnsiString (code page 1252) are needed;
- generic string for i18n (e.g. in unit SQLite3i18n), i.e. text ready to be used within the VCL, as either AnsiString (for Delphi 2 to 2007) or UnicodeString (for Delphi 2009/2010/XE);
- RawUnicode in some technical places (e.g. direct Win32 *W() API call in Delphi 7) - note: this type is NOT compatible with Delphi 2009/2010/XE UnicodeString;
- RawByteString for byte storage (e.g. for FileFromString() function or BLOB temporary storage);
- some special conversion functions to be used for Delphi 2009/2010/XE UnicodeString (defined inside {$ifdef UNICODE}...{$endif} blocks);
- never use AnsiString directly, but one of the types above.
I would like to use Zeos as the database layer for my upcoming project, named mORMmot - http://synopse.info/forum/viewtopic.php?id=143
My proposal is that I could make a whole code refactoring using UTF-8 as internal format of the ZEOS layer, with some types similar to the one I quoted above.
Then the team could take it as a start.In all cases, I'll start a fork of ZeosLib for our little mORMot.
Offline
#8 2010-11-21 09:28:22
Re: Close future of the framework: database agnosticism
About UTF-8 support in various databases:
- Firebird supports UTF-8 encoding since version 2.0, via the UTF8 character set - see http://www.destructor.de/firebird/charsets.htm
- MySQL supports UTF-8 encoding since version 4.1, via the utf8 character set - see http://dev.mysql.com/doc/refman/5.5/en/ … -utf8.html
- PostgreSQL supports UTF-8 encoding since version ??, via the UTF8 character set - see http://www.postgresql.org/docs/8.1/inte … ibyte.html
- Microsoft SQL Server: SQL Server 7.0 and SQL Server 2000 use a different Unicode encoding (UCS-2) and do not recognize UTF-8 as valid character data. So the UTF8 encoding must handled client-side, as stated by http://support.microsoft.com/kb/232580
- Oracle supports UTF-8 encoding, as stated by http://download.oracle.com/docs/cd/B193 … tm#g681427
In all cases, we'll have to handle UTF-8 from the client side (i.e. ZeosLib/mORMot) and define the most "native" (or wanted - UCS2 is a need for MSSQL and if you use asiatic characters, it does make sense to store your data using UCS2/UTF16 instead of UTF-8) parameter from the server/table creation side.
Offline
#9 2010-12-01 14:43:09
- migajek
- Member
- Registered: 2010-10-01
- Posts: 89
Re: Close future of the framework: database agnosticism
Hi,
may I ask you what is the progress of integrating ZDBC to the Framework? 
Offline
#10 2010-12-01 16:26:00
Re: Close future of the framework: database agnosticism
Check the link above: http://zeos.firmos.at/viewtopic.php?p=12484#12484
ZEOS Core has been converted to UTF-8, and now uses SynCommons RawUTF8 types and functions.
Check http://synopse.info/fossil/info/7810952a31
ZDBC is on its way.
Offline
#11 2011-06-10 09:16:02
Re: Close future of the framework: database agnosticism
Let's quit ZEOS.
Too much work, debugging, testing...
Here is my new proposal: http://blog.synopse.info/post/2011/06/0 … gnosticism
Offline
#12 2011-06-27 19:36:25
Re: Close future of the framework: database agnosticism
.... and here is the working SynOleDB unit!!!
http://blog.synopse.info/post/2011/06/2 … -via-OleDB
See also http://synopse.info/forum/viewtopic.php?pid=2214#p2214
Offline
#13 2013-12-06 10:23:30
Re: Close future of the framework: database agnosticism
... and Zeos is back!
ZDBC 7.2 (the latest unstable branch) just rocks, and has been enhanced to be UTF-8 by the official maintainers.
Thanks Mark & Egon for all your good work!
Offline