Re: [office] OpenDocument TC Meeting Minutes 2005-08-8

[Michael Brauer <Michael.Brauer@Sun.COM>]

Hi all,

I've asked Frank Schönheit for a clarification of the open issues regarding
the database front end proposal

Best regards

Michael

Lars Oppermann wrote:
> 
> Database Proposal
> -----------------
> 1. Seperation of  Driver/App-Settings should be kept. Driver parameters 
> are relating directly to the way the datasource is accessed. Application 
> parameters relate to how the data recieved from the driver is to be 
> handled by the application

The following should be moved from "Application Connection Settings" to
"Driver Settings":
- Parameter Name Substitution
- Auto Increment (including its attributes)

> 2. An exclude-pattern should be added to the table-filter. It should be 
> evaluated after the include-pattern is processed and be applied to the 
> result of the include-filter.
> 
> 3. db:default (default for column)
> should only be evaluated by the application, not by the driver. Should 
> reuse value and valuetype fields.

Reusing the  value/type attributes specified in section 6.7.1 is possible.
They specify more than what is needed, in particular, in the database
context there's no use for "currency", but can express everything what is
needed.

> 
> 4. String values for char-encoding
> needs to be clarified

The assumption made throughout the document is that the
only layer doing an encoding/decoding is the driver. The
db:character-set sriver setting specifies how a driver should translate
strings when passing from/to a non-unicode capable backend. This should
be applied to string default values, too.

> 
> 5. a better name for db:table is needed, since it is not a real table 
> definition which it implies.

I'd prefer "table-presentation", to indicate that it describes how
the application presents the table/data to the user. "Table view" could
be confused with server-side views, and thus should be avoided.

> 
> 6. datatype mapping should be optional. defaults should be provided by 
> the driver

The SQL data type specifies, if you want, a "type
class", while the internal data type (completely) specifies the real
data type.

For example, MySQL has the following internal types which all have the
same SQL type (integer): "integer", "int", "mediumint", optionally
combined with "unsigned", and independently optionally combined with
"auto_increment". That is, "int unsigned auto_increment" is one of
12(!) possible data types which all have the same SQL type "integer".

If a mapping from either the SQL or the internal type or vice versa would be
specified within the driver settings, then the columns definition would,
whenever possible, only specify one of the two types.

- Specifying the internal data type only would not be interchangeable between
  different backends and would require an analysis of the driver settings to
  actually get the SQL type. For this reason, specifying only the internal
  data type seems not to be reasonable.

- Specifying the SQL data type only allows interchangeability (in fact,
  if a db:schema-definition would be applied to a backend different from
  the one for which it was created, the backend-specific internal data
  type would have to be ignored, anyway). But because there could be much
  more internal data types than there are SQL data types, the default mapping
  in the driver would only work in very few cases. This means that in most
  situations, both data types have to be specified, and that the
  default mapping specified in the driver settings has not much benefits.


> 
> 7. since db:is-nullable is an optional attribute, the nullable-unknown 
> value should be removed, since this is what is imlied by the attribute 
> not being specified.
>