KOffice Integration

 started: April 2005, mart

See also Available Jobs in KOffice Integration

Table of Contents    1. KSpread data integration      Overview      Design Goals      Storyboard      Design    2. Reusing KSpread's expressions

1. KSpread data integration ^ toc

Overview

Currently, KSpread can import data from databases using the QtSQL framework. There are some problems with the current implementation (although these are certainly not the fault of the author of this feature).

• The user needs to know all the connection parameters for the given database.
• It can't make use of queries stored in the database's system tables.
• The user interface for querying the DB could be simpler.
  • Should be based on familiar query editor in Kexi.
• It would be better as a plugin (see KSpread's insertcalendar for example).

Design Goals

Functional:

• Provide an improved static DB import facility for KSpread
• Allow data to be imported from Kexi databases
  • Tables (stored in the database)
  • Queries (stored in the database)
  • Custom queries (defined during data import)
• Allow data to be imported via Kexi's Migration framework
• Maintain QtSQL functionality, for DB's not supported by Kexi

Non-functional:

• User interface should be as consistent as possible
  • Regardless of data source, or it's capabilities

It may be possible to maintain existing QtSQL functionality for DBs unsupported by Kexi, my implementing a QtSQL driver for Kexi, or a QtSQL migration driver. Obviously, the actual implementation used to import the data should be transparent to the user.

It should also be possible to use password stored in the user's KWallet, if Kexi has stored it there.

Storyboard

Step 1: Choose a database

Step 2: Provide a query

Either: (2a) Use data from a table stored in the database (or query if source is a Kexi DB) We can use the same dialog that we will use for selecting a table/query for reports. Ideally, something like the following, without the radio buttons. If the source is a Kexi database, we should show all tables and queries in the same list (perhaps with icons to distinguish between them). If not, just the list of tables.

Or: (2b) Allow the user to provide their own query

It might be interesting to allow the user to modify an existing query within the database.

Design

The current Migration Framework only imports to Kexi DBs. There are two ways we could reuse these drivers:

1. Import the data to a Kexi database first, query it, and copy the result into the spreadsheet.
2. Define an API for objects that can recieve rows of data. Then:
   • Define a subclass that copies the rows to a Kexi DB.
   • Define a subclass that copies the rows to a KSpread sheet.

The first method has the advantage that we can easily use the query editor to define queries on the imported data. However, the new database would need to be copied into a temporary database first, and will be less efficient.

The second method is more efficient, but limits the ability to query the database.

2. Reusing KSpread's expressions

Following things can be reused:

• expression parser (we're not sure we want/need it as we may also use KexiDB Expression Parser or KROSS/Python parser)
• builtin function's library (we want that!)