[Fwd: Re: proposal submitted at OASIS]

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

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.

General note: I am not sure about a reason for exchanging driver settings
e.g. between applications like Kexi and OO.org Base, if these settings are
hidden in implementation. The problem is that the settings define behaviour
and/or capatibilities of database backends. For example, "Row Retrieving
Statement" attribute is what application needs to know, but I am not sure how
it is related to database schema exchangeability? Could you please help me by
providing a usage scenario?
(One thing coming to my mind is that the format for describing driver's
settings can be used by database server vendors to describe requirements and
capatibilities of their backend, so 3rd party drivers impelmentation can rely
upon such description)

Related note A: I've considered "application settings" to be much
database-independent, i.e. representing a set of settings from a higher level.

Related note B: On the other hand, db:max-row-count attribute looks like a
sane application-wide setting, as it's largely driver-independent and can be
considered as one of settings provided for efficiency-tunning purposes.

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).


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
not specified character encoding for the string (it can be inherited from
other settings though).

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.


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.


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".

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska / Kexi Team
  http://www.openoffice.com.pl  |  http://www.kexi-project.org
  KDElibs/Windows: http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32