[Libreoffice-bugs] [Bug 124022] New: Unhardcode different driver default settings

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=124022

            Bug ID: 124022
           Summary: Unhardcode different driver default settings
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Base
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: mikekaganski at hotmail.com
                CC: lionel at mamane.lu, serval2412 at yahoo.fr

Currently there are several places where different connection setting defaults
are defined: in respective
connectivity/registry/<driver>/org/openoffice/Office/DataAccess/Drivers.xcu; in
ODatabaseModelImpl::getDefaultDataSourceSettings
(dbaccess/source/core/dataaccess/ModelImpl.cxx); in
ODbAdminDialog::createItemSet (dbaccess/source/ui/dlg/dbadmin.cxx); in
ODBExport::exportDataSource (dbaccess/source/filter/xml/xmlExport.cxx); in ODF
standard/XML schema (for attributes like db:is-table-name-length-limited).

The defaults are used to create new connections, or when opening existing
connections; when writing values back (to skip writing those that have values
equal to defaults); when showing advanced settings dialog, and when applying
its result to the open database.

Having the default values for some setting not in sync in different such places
creates problems, like those in tdf#121092. E.g., having conflicting defaults
for a boolean setting in Driver.xcu and in
ODatabaseModelImpl::getDefaultDataSourceSettings disables writing such setting
to ODB completely (because any of its values is considered default at different
levels, and is skipped). Having conflicting defaults in Driver.xcu and in
ODbAdminDialog::createItemSet makes Advanced Settings dialog to show wrong
value for a setting which is absent in ODB (so the value used is the default
from Driver.xcu, but dialog shows different setting). And so on.

Having a single ODatabaseModelImpl::getDefaultDataSourceSettings makes it
impossible to have different defaults for different drivers (because of the
mentioned problems) - so effectively this mandates that all drivers have same
defaults which are equal to those in
ODatabaseModelImpl::getDefaultDataSourceSettings, breaking the per-driver
mechanism.

Additionally, skipping writing of the settings to ODB which are equal to
defaults creates another problem: an ODB only has settings which are not equal
to the defaults *of the version which was used for its last saving* - and if
opened in another version with changed defaults, the missing settings take new
default values, which may break the connection.

Taking all of the above into account, the proposal is to reimplement this:

1. Make ODatabaseModel(Impl) to update its defaults from Driver.xcu as soon as
it knows the connection type - so that
ODatabaseModelImpl::getDefaultDataSourceSettings only provides lowest-level
common defaults, which would be overridden by those from Driver.xcu - this
would allow per-driver defaults;
2. Make all other places where defaults are consulted (like
ODbAdminDialog::createItemSet) to take defaults from the ODatabaseModel, and
remove own hardcoded default sets - this would simplify defaults management and
remove redundancy;
3. Always write all setting values to ODB, regardless of if they are equal to
defaults or not, to allow to change driver defaults when it makes sense, and at
the same time, not break existing working ODBs (the only exception may be
settings which defaults are defined by standard);
4. To allow to change connection type and have defaulted settings to update to
the new type's defaults, at run-time, when the type of connection changes, male
list of all default-valued settings and modify them accordingly.

This possibly might me made an easy-hack (difficulty interesting) - but I must
say that I cannot help much an interested developer. On the other hand, this
might be too much for an easy hack...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190312/bb80ee91/attachment.html>