kexi project
Rapid Database Application Development
"Microsoft Access for Linux"

Home Download FAQ Support Features Handbook Screenshots Screencasts Compile Kexi Development Authors Contact License Sponsorship Translate This Site

wiki navigation:

Front Page
[info] [diff] [login]
[recent changes]
[most popular]
You can donate
to Kexi Project:
Via PayPal

Spread the word about Kexi!
Get Kexi Now!

Built on the KDE technology

Member of the Calligra Suite

No Software Patents!


Loopback Driver

 started: may 2005
 maintainer: jstaniek
 status: planned

Table of Contents
   Other Issues
     Isn't reading kexi__** tables enough?
     How does connecting with this driver look like?


Yeah, this time, it's a real hardcore: you get a driver which does introspection into plugged databases' schemas and returns available information in a form of virtual database Views.

^ toc


Most important views can be:

 VIEW objects( id integer, name integer );
 VIEW table_fields( table_id integer, name integer,
                   primary_key boolean, ... );

then, you can

 SELECT as table_name, table_fields.field_name
 FROM objects, table_fields WHERE;

to get a overview of database tables and fields, eg. for creating design report.

^ toc


To escape from a need for writing special code for generating automatic reports describing project objects' (tables/queries/etc) properties. With the Loopback driver we can just generate a report based on a virtual data view, and the job is done. Basically we want to cast contents of all kexi__** "system" tables to these virtual views.

Thus, we also get alternative way for objects introspection: by running a query, like:


instead of using:

^ toc

Other Issues

^ toc

Isn't reading kexi__** tables enough?

Could be true, but eg. constraints within table field information is packed in a single integer. The table_fields view can provide them in a single-flag-per-column way. But also imagine a (dynamic) information about a table from a linked native database, e.g. this:

 VIEW linked_table_fields ( table_id integer, name integer,
                            primary_key boolean, ... );

Every time you're querying this view you can get different values as all this is retrieved from a native database, able to change independently from Kexi.

^ toc

How does connecting with this driver look like?

We're allocating virtual KexiDB::Connection object. But note the differences between Loopback connection and "regular" one:

  • the Loopback driver will not be available within GUI (especially, not in connection dialog's list of drivers during application startup nor during project migration).
  • despite above, we can provide a project-wide option called "Show system objects" (MSA has this option as well)
  • the connection is read only (at least we're assuming this for now)
  • the connection is tied to an opened project: there is one such connection (we can make it available within KexiProject(external) in a global space.
^ toc


Implementation of the Loopback driver depends on having:

  • Database Views in KexiDB (not yet available, but in fact it's similar to table schemas)
  • Multiple opened conenctions within a single project instance (not yet available)

Optional dependency: linking native databases to a project.

Kexi - "MS Access for Linux" ... and Windows
© Kexi Team
This content is available under GFDL
Last edited: May 11, 2005 by js, visited 0 times.