You are not logged in.
Pages: 1
We would like to have native support in mORMot for NexusDB database servers, supporting both the embedded server possibilities of Nexusdb and the remote server possibilities.
Performance is a very big issue, so we don't want to introduce any extra layers by using OLEDB.
How do we start creating this SynDBNexusDB.pas? (or maybe somebody already has started work in this ;-)?)
What kind of already existing unit-tests can we use to determine if our implementation is complete and in working order?
Offline
At first, re-read the documentation about SynDB implementation: you have features and class hierarchy of the abstract classes to be overriden.
A starting path for SynDBNexusDB.pas could be the SynDBSQLite3 unit.
The 3 implemented classes are the one to be implemented. The SynDBSQLite3 unit is in fact very thin: it is just an efficient wrapper above the SQlite3 engine.
For best performance, you should better directly override a TSQLDBNexusDBStatement.ColumnsToJSON(WR: TJSONWriter) method, and a TSQLDBNexusDBStatement.ColumnToVarData() method also (see SynDBOracle unit for a sample implementation code).
The regression tests using TSQLDBSQLite3ConnectionProperties can be reused to test your implementation.
I never used NexusDB, but sounds like a nice library.
Since it sounds like DB.pas-based (which is good for RAD components, but oversized in comparison to SynDB implementation classes), I see two implementation patterns:
- Map TnxQuery into a TSQLDBNexusDBStatement, with the associated properties and connection (mapping a TnxSession);
- Map more abstract TDataSet, i.e. supplying the IProviderSupport methods.
I guess the most "elegant" solution should be the 2nd, i.e. mapping TDataSet, since it will allow to use any DB.pas-based libraries (i.e. almost all in Delphi).
But the faster and easiest to implement is definitively the one using TnxQuery.
Honestly, I'm not sure NexusDB should be much faster than SQLite3 in Synchronize := smOff mode.
Using the TDataSet abstract class is certainly a bottleneck, which does not exist with our SynDB and SynSQLite3 classes.
The benchmarks available at http://blog.synopse.info/post/2012/07/26/ACID-and-speed states very high performance (42,000 rows per second for insert, 170,000 rows per seconds on reading).
Of course, using NexusDB would allow to reuse a lot of existing code for you, which does make a lot of sense.
That is:
- Deploy existing code as mORMot services;
- New code could use mORMot ORM to work with the DB.
Offline
Thanks for your suggestions, they are really usefull!
The reason we are looking for this extra implementation is that the current version of our product make heavy use of NexusDB. We are in the start-up of developing a major overhaul of our application, and of course cannot ignore our installed base, even it is only necessary to convert to a better solution ;-)
We'll will keep you posted on our progress, and of course will supply you with the resulting unit
Offline
Pages: 1