KDb/Drivers/Loopback: Difference between revisions
m Jstaniek moved page Kexi/KexiDB/KexiDB Drivers/Loopback to KDb/Drivers/Loopback |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
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. | |||
__TOC__ | |||
== 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. |
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.