Rapid Database Application Development
"Microsoft Access for Linux"
started: may 2005 maintainer: jstaniek status: planned
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 objects.name as table_name, table_fields.field_name FROM objects, table_fields WHERE objects.id=table_id;
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:
SELECT * FROM TABLES WHERE name="foobar"
instead of using:
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:
Implementation of the Loopback driver depends on having:
Optional dependency: linking native databases to a project.