LAB Project Overview
The schema gives a simple view of the 4 main "universes" included in LAB Project.
- First we find a Physical Layer which shows a few database backends. Note that a LAB Project application can use as many of them as you need simultaneously.
- Then you can see the two parts of QlabLibrary wich show the interaction between the data management layer and the data presentation layer.
- Next, the Module Interface layer relies on the user interface (look & feel only), the INI parameters and a main() function.
As the schema shows, QlabLibrary is the master block of the system while the labmodule represents only the glue to get the whole thing together.
- Note:
- Even if the graphic does not imply it, the main() function can be as short as less than 10 lines, including the standard declarations and includes. If you use the very good Qt Designer from Trolltech to design your user interface, you reduce the real coding to quite nothing, as LAB Projects integrate smoothly into Qt Designer.
The next sections of this chapter will explain the parts in more details.
The physical layer is constituted by network connectors to various database back end servers. This has nothing to do physically with Lab Project, but is mandatory to present the repository participants. This part of the schema is here to show the real interface for Driver Lib Slots in QlabLibrary.
QlabDatabase::QlabDatabase() class can dynamically load drivers for the following database servers:
- DBM, nDBM, GDBM: Those are very simple non SQL database engines. They store their data in hash tables with simple indexes. We do not recommend them for big tables with more than 1 million entries, as they become slow on huge tables. Integrity of data cannot be guaranteed with them. But they are really nice for small static tables.
- Xbase (dBase, FoxPro, Clipper...): This is a generic driver for all dBase, FoxPro, Clipper data. All variations on memo fields and indexes are implemented. We made this driver as many Clipper or dBase applications sit around in many companies, most dating from good old MS-DOS days.
- Concept ASA DB++: This german database system is widely used in northern Europe. It is very fast, powerful and stable. We only connect to this one for peeking data, but do not support its scripting language.
- Flat File: This can be classic files sitting in a directory, old flat databases found on old mainframes, RDF or delimited files and more.
- FrontBase Terabyte Data System: FrontBase is a very powerful and works on MacOS X.
- FilePro: Unusable for real production, due to very limited capacities. Our driver is a read only reader, allowing migration to MySQL, PostgreSQL or other real databases.
- Hyperwave Information Server: Non structured database really powerful. We find it on some data mining applications.
- IBM DB2: This is a classic SQL system. Native access is great, the system is very robust and has honorable performances. IBM ODBC driver is buggy and very slow.
- Informix 7, Universal & 2000: Used by some ERP Systems. Performance and robustness are its key words.
- Interbase: Borland SQL server implementation. Many Windows applications made with Delphi use this format.
- Firebird: is a free Interbase implementation with the same features. Sounds fast and robust.
- Ingres II: This canonical database is widely used on mainframes. We had to tweak some queries to get it perform as we intend due to some limitations in SQL dialect.
- LDAP Server: Seldom use as database, but we connect to it for its very good ident an directory services.
- Microsoft SQL Server: Even if this cannot be used on highly charged systems and its bad response time, the fact that a huge range of applications use it made us build a driver for it. We use native access via the excellent FreeTDS libraries. Only for versions 7 and up.
- MySQL Server: The Open Source star database. It is famous for its performances, excellent load, and good support. We add its impressive replicator to the chorus of good news.
- Open ODBC, iODBC, UnixODBC, ODBC Bridge: All are supported to allow connections where native connect is impossible or interface not documented by vendor, such as Adabas from Software AG.
- Oracle 8, 8i et 9: This is the reference database server. We support full Oracle API.
- Ovrimos: As we meet this beast (which is very powerful) as often as a giraffe in a kitchen, we only have a basic preliminary support for this.
If some Ovrimos users send us technical information about interface, this will eventually grow to full support. For production, you should use ODBC for now.
- PostGreSQL: This very robust relational/object database is robust and fast on huge read-only tables. However, the vacuum process may be very slow and performance issue on live tables.
- SESAM SQL: This is a Fujitsu/Siemens mainframes specific database. A preliminary support in native mode is under development. For production, till full support is done, use ODBC connectivity.
- SQlite: NEW Full support is now integrated. Sorry, we could not test it on very huge database, so we recommand using it on medieulm sized databases (less than 70 Gigas).
- Sybase: This robust database is fast and reliable on medium sized database. Its main drawback is lack of reliable support for tables larger than 2 gigabytes. Support is done via (excellent) FreeTDS library.
- Note:
- Some other database are supported and new support is added when we get information and development kits.
Architecture Overview | LAB Project Overview
The QlabLibrary is a compound library which is mainly composed of 2 sets:
This library module defines most of the LAB Project Foundation classes. - Note:
- All Driver Lib Slots entities will NEVER be instanciated by application programmers. They are only an opaque interface to physical backends and are only presented in the abstract Data Repository definition file to determine what backend owns a named data collection.
For internal use only.
This module only presents an abstract method collection and a grip to dlopen() system call for dynamic loading of needed backend interface libraries.
Please refer to Physical Layer for a full list of supported backends.
The various classes dealing with backend drivers are NOT exported to application developpers and are only accessible via an opaque interface to other QlabDatabase entities modules.
All backends support the following methods:
- select() for data selection.
- index(), sort() for data sorting.
- setFilter(), prepare(), bindValue() to subset the retrieved data.
- first(), last(), next(), prev(), seek() to navigate the dataset.
- value() and setValue() to get or set individual items from a data object.
- calculated() to retrieve virtual calculated data.
- insert(), update() and del() to create, modify or delete data objects.
- supportedFeatures() to get a list of other supported features. This deals with backend specific supported features such as internal triggers, stored procedures...
QlabDatabase entities | Architecture Overview | LAB Project Overview
For internal use only.
This module is totally opaque to application programmers. It is only used internally by QlabDatabase entities participants to determine which backend owns what in the data collection. It gets the LAB Project standard Data Collection definition skeletons at startup and builds the virtual connections when necessary.
It is only used by some data access classes. Those are tweaked versions of Qt database classes, modified to get their real parameters from the schema translator.
- Todo:
- Write a complete description with code snippets showing the real interaction between the Translator and other modules.
Prepare a complete description of the caching mechanism and the rotating bufferization implementation.
Write a more descriptive text with some nice pictures and snippets to let the mechanism be really understandable.
Write a complete tutorial about the extended dl() method and the netfetchmodule() interface.
QlabDatabase entities | Architecture Overview | LAB Project Overview
For internal use only.
This module presents the same interface as Driver Lib Slots to wich it acts as a transparent front end.
It has only one goal, dataset caching to speed up all data recovery.
QlabDatabase entities | Architecture Overview | LAB Project Overview
This module is the real front end to the DataCollection caching module. It gets the standard Driver Lib Slots interface.
Technically, this is the key of QlabDatabase entities system, as it is the only published interface between the Widget Manager entities and the real data. Its main feature is getting the standard query, say a filtered select on a data view, translate the query in something the backend will understand by querying DataCollection Schema Translator about the pros and cons of the needed dialect, rewrite the query according to DataCollection Schema Translator information and pass the baby to the cache. The cache then checks if it already as an answer ready. If so, it sends the answer. Else, the query is fed to the Driver Lib Slots after a new check by the schema translator.
- Note:
- If the prepared query involves more than one backend connection, the last schema translator check cuts the query in pieces, rewrites it as individual queries and sends the thing to needed backends. When it has the answers from all backends involved, it grabs the answers and rewrite them as a unified answer meeting the query criterias and sends it back to the cache who stores the thing for future use and feeds the Data Requesting Translation back.
QlabDatabase entities | Architecture Overview | LAB Project Overview
This module set defines the relationship between QlabDatabase entities interface and the user. Its main role in this affair is providing the user (and the developer) with most of the needed ways to beg the data collections for information, format them as needed (lists, trees, tables, selectors...) and show them in a transparent way.
The 4 level mechanism has been set up to present a really unified interface to most data. The Widget Pool can evolve with time with more and more widget definitions. When sitting in pool, the widget becomes available for each and every user interface, be it statically bound by developers or dynamically available to users themselves via the QlabOptionEditor::QlabOptionEditor() interface.
This module embeds in libraries a bunch of widgets. The available widgets are shown in Widget Pool hierarchy. Libraries share the standard plugin mechanism. Most offer a designable as well as a scriptable interface, allowing graphic parametrization in User Interfcae design tools suc as Qt Designer or the forthcoming LAB Project Aplication Designer.
The pool only contains widgets definitions. Most of the definition are stored in a System Table in the main Data Collection, allowing network wide instanciation and on the fly download.
Widget Manager entities | Architecture Overview | LAB Project Overview
Widget Manager entities | Architecture Overview | LAB Project Overview
Widget Manager entities | Architecture Overview | LAB Project Overview
Widget Manager entities | Architecture Overview | LAB Project Overview
Architecture Overview | LAB Project Overview
