Re: [office] [Fwd: Re: proposal submitted at OASIS]

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

Hi all,

Michael Brauer wrote:
> Hi all,
> 
> Jarosław Staniek from the KOffice team asked me to forward his comments
> regarding the Database Front End proposal to our mailing list.
> 
> Best regards
> 
> Michael
> 
> 
> -------- Original Message --------
> Subject: Re: proposal submitted at OASIS
> Date: Mon, 01 Aug 2005 12:17:43 +0200
> From: Jarosław Staniek <js@iidea.pl>
> Organization: Open Office Polska
> To: Michael.Brauer@Sun.COM
> CC: Frank Schönheit - Sun Microsystems Germany <Frank.Schoenheit@Sun.COM>,
> dfaure@kde.org
> References: <42E72817.1040806@sun.com>
> 
> Frank Schönheit - Sun Microsystems Germany said the following, On 2005-07-27
> 08:22:
> 
> 
>>I think it should cover most, if not all, of your original concerns.
>>
>>Could you please have a look at it, and provide David Forr with
>>feedback, so he can carry it into the OASIS TC?
> 
> [...]
>  > Since David is (AFAIK) on vacation currently, you might well send them to
>  > somebody else in the TC - I suggest Michael.Brauer@sun.com for simplyicity
>  > Frank
> 
> Dear Michael,
> 
> I am satisfied with most of the specs, more usable than before. Small notes
> for not so obvious issues follow:
> 
> 
> 1. What about moving most of elements from <db:application-connection-settings>
> to <db:driver-settings> ?
> 
> Things like "db:parameter-name-substitution" attribute are even described by
> statements like "Some databases do not allow named parameters in SELECT...".
> "Is Table Name Length Limited" or "Suppress Version Columns" are clearly
> static properties of a given db backend implementation, so we may ask: why a
> user may want to restrict himself in this area. Even powerusers usually expect
> things work transparently without a problem using default properies provided
> by db drivers.
> Summing up, many of such attributes are not user-visible and just belong to
> client and/or server-side implementation, thus could belong to driver's
> settings.
> My note doesn't meant a user may be able to see or edit mentioned settings,
> but it only means these settings can just belong to driver's attributes.
> Other reasoning: what if more than one application uses a set of db
> drivers? With the change I proposed, they could share settings delivered by
> drivers.

From my understanding, driver settings should be settings that a database
driver requires to operate or that are required to use a database driver.

Application settings are settings that describe how the application presents
or processes the data that it retrieves from the database.

So, I agree that the "db:parameter-name-substitution" attribute should be a
driver setting, but "Suppress Version Columns" still should be a application
settings, because it simply states that version columns should not be displayed.

If we have agreed what the two kinds of settings should mean actually, then
it seems to be best if we go through all settings in detail and check into
which category they match. Maybe it is also reasonable to rename the two classes.

[...]

> 
> 2. <db:table-filter> element. Extension proposal: What if we want to exclude a
> group of tables? I'd like to have such possibility to hide "KexiDB system"
> table (defined by "kexi__" name prefix).

Having such a feature seems to be reasonable. Jarosław or David, can you
please create a proposal how this could look like in the OpenDocument schema.

> 
> 
> 3. db:default-value attribute represents a string for a default value. Perhaps
> we may want to explicity specify how to encode default values for non-string
> data types, like floatin point numbers, date/time, and so on. Moreover, we've

What about reusing the office:value-type and office:value attributes
specified in section 6.7.1 of the OpenDocument v1 specification?

> not specified character encoding for the string (it can be inherited from
> other settings though).

I don't think we need a character encoding for string default values. From my
understanding, default values are displayed by the application without
passing it through the database engine, But even if default values are passed
to the database engine, then no separate encoding definition is required,
because there is already one in the driver settings.


> 
> Related issue: db:default-value attribute is defined for both:
> db-column-attlist and db-column-definition-attlist. At more general level the
> question is: could information provided by <db:schema-definition> and
> <db:tables> be merged? As we know, 'schema' construction is supported by some
> db backends. If <db:tables> is a definition of physically existing table and
> <db:schema-definition> is a definition of it's schema, then for example, for
> Kexi, tables are physically created using schema defined by user, and when
> schema is altered, it is used to recreate tables physically (how this is easy
> to implement depends on having good ALTER TABLE support). That's why I
> proposed to merge column definitions. Please tell me about additional
> constraints I may not be aware of.

I don't think that <db:tables> and <db:schema-definition> can be merged. A
<db:schema-definition> describes a database table as it is physically
existing within a database. In contrast to this, the <db:tables> element
described a view of tables or how a database table actually is displayed.
Both definitions are independent of each other, that is, the view of a table
could be independent of its physical representation.
> 
> 
> 4. db:type-name attribute "indicates the database dependent type name of a
> database column. Depending on the database vendor, different type names can
> have identical data type". My proposal is to move such translation
> (custom-type -> standard-SQL-type) to driver's definition, thus making
> database schema more backend-independent and easier to exchange. It's often
> easier to deal with predefined set of type names and only translate them to
> custom names when talking to the db backend.

From my understanding, a mapping from custom types to standard SQL types does
not exist, but a database engine requires both, the custom type and and the
SQL type to uniquely identify a table column's data type. This means that we
need both types within the schema definition, too.

> 
> 
> 5. For db:is-nullable attribute, is 3rd value "nullable-unknown" needed?
> I guess that since db:is-nullable is declared as optional, ommiting it could
> mean the same as "nullable-unknown".
> 

You are right. The value "nullable-unknown" is useless, because it has
exactly the same meaning as ommitting the "db:is-nullable" attribute.


Best regards

Michael