<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Unhardcode different driver default settings"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=124022">124022</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Unhardcode different driver default settings
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Base
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mikekaganski@hotmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>lionel@mamane.lu, serval2412@yahoo.fr
</td>
</tr></table>
<p>
<div>
<pre>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 <a class="bz_bug_link
bz_status_NEW "
title="NEW - Libreoffice 6.1.3.2 does not allow saving Advanced Properties options with SQLITE 3 over ODBC"
href="show_bug.cgi?id=121092">tdf#121092</a>. 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...</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>