KDb/Drivers/Loopback: Difference between revisions
No edit summary |
|||
(One intermediate revision by the same user not shown) | |||
Line 3: | Line 3: | ||
started: may 2005 by jstaniek | started: may 2005 by jstaniek | ||
status: idea and some design, volunteers needed | status: idea and some design, volunteers needed | ||
The Loopback driver is a higher-level driver that performs introspection into plugged-in data sources and returns available information in a form of db views. | |||
__TOC__ | __TOC__ | ||
== Example == | == Example == | ||
Line 32: | Line 32: | ||
KDbConnection::tableSchema("foobar") | KDbConnection::tableSchema("foobar") | ||
== How would it be used in KEXI? == | |||
A KDbConnection can be allocated but note the differences between Loopback connection and "regular" one: | |||
* the driver will not be generally available within KEXI GUI (not in connection dialog's list of drivers) | |||
* despite above, it's possible to provide a project-wide option called "Show system objects" (MSA has this option as well) | |||
* the connection is read only (at least that's the assumption for now) | |||
* the connection is tied to an opened project: there is one such connection (we can make it available within a KexiProject object in a global space. | |||
== Dependencies == | |||
Implementation of the driver depends: | |||
* Database Views in KDb (not yet available, but that's similar to table schemas) | |||
* Multiple opened connections within a single project instance (not yet available) | |||
* Optional dependency: linking native databases to a project. |
Latest revision as of 21:26, 6 April 2023
Design document
started: may 2005 by jstaniek status: idea and some design, volunteers needed
The Loopback driver is a higher-level driver that performs introspection into plugged-in data sources and returns available information in a form of db views.
Example
Most important db views can look like the Schema Table of SQLite https://sqlite.org/schematab.html
CREATE TABLE sqlite_schema( type text, name text, tbl_name text, rootpage integer, sql text );
Then, you can perform SELECT queries on the table.
Why?
This feature gives the overview of database objects and fields, eg. for creating a design report without a need for custom coding. As a consequence, e.g. KEXI can display data from this table as from any other tables, if this KDb driver is accessible.
We also get alternative way for schema introspection: by running a query, like:
SELECT * FROM TABLES WHERE name="foobar"
instead of using the KDb API (pseudocode):
KDbConnection::tableSchema("foobar")
How would it be used in KEXI?
A KDbConnection can be allocated but note the differences between Loopback connection and "regular" one:
- the driver will not be generally available within KEXI GUI (not in connection dialog's list of drivers)
- despite above, it's possible to provide a project-wide option called "Show system objects" (MSA has this option as well)
- the connection is read only (at least that's the assumption for now)
- the connection is tied to an opened project: there is one such connection (we can make it available within a KexiProject object in a global space.
Dependencies
Implementation of the driver depends:
- Database Views in KDb (not yet available, but that's similar to table schemas)
- Multiple opened connections within a single project instance (not yet available)
- Optional dependency: linking native databases to a project.