Why?

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:

Other Issues

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: