Bug 124022 - Unhardcode different driver default settings
Summary: Unhardcode different driver default settings
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Connectivity
  Show dependency treegraph
 
Reported: 2019-03-12 12:15 UTC by Mike Kaganski
Modified: 2021-03-27 04:07 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-03-12 12:15:54 UTC
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...
Comment 1 Roman Kuznetsov 2019-03-13 10:38:51 UTC
Let's set this to NEW
Comment 2 Xisco Faulí 2019-03-14 09:02:42 UTC
Hello Mike,
Do you think this could become a task for GSOC ?
Comment 3 Mike Kaganski 2019-03-14 09:06:11 UTC
(In reply to Xisco Faulí from comment #2)

Possibly - but:
1. I wanted to have some discussion first - I know too little about the topic, and it happened to me when I tried to fix a bug, not because of deep understanding;
2. Even if it's worth doing, as I mentioned, I'm not able to mentor.
Comment 4 Xisco Faulí 2019-03-14 09:09:00 UTC
Yep, sure, I'm not saying you should mentor it.
Do you think it should be discussed in the dev list first ?
Comment 5 Christian Lohmaier 2019-03-27 12:01:21 UTC
adding commend from outage:
https://lists.freedesktop.org/archives/libreoffice-bugs/2019-March/176627.html
--- Comment #5 from Lionel Elie Mamane ---
(In reply to Mike Kaganski from comment #0)

> so effectively this mandates that all drivers have
> same defaults which are equal to those in
> ODatabaseModelImpl::getDefaultDataSourceSettings, breaking the per-driver
> mechanism.

IMO, having per-driver defaults is important. SDBC drivers that know which
database they connect to (e.g. MySQL, PostgreSQL, as opposed to e.g. ODBC,
JDBC, ADO) should just set the right values by default silently, and not even
give the user UI to change them to known non-working values.

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

In the context of DBMS-specific drivers, on the other hand, when the default is
wrong, it allows changing the default, and fixing the connection in newer
LibreOffice versions. Else, we fix it only for files created in the new
LibreOffice version.

https://lists.freedesktop.org/archives/libreoffice-bugs/2019-March/176630.html
--- Comment #6 from Mike Kaganski ---
(In reply to Lionel Elie Mamane from comment #5)
> IMO, having per-driver defaults is important. SDBC drivers that know which
> database they connect to (e.g. MySQL, PostgreSQL, as opposed to e.g. ODBC,
> JDBC, ADO) should just set the right values by default silently, and not
> even give the user UI to change them to known non-working values.

No doubt here. My point is that currently that is broken, and must be fixed by
removing the mess when some pieces of code take one set of defaults into
account, and other takes other set, which leads to errors.

> In the context of DBMS-specific drivers, on the other hand, when the default
> is wrong, it allows changing the default, and fixing the connection in newer
> LibreOffice versions. Else, we fix it only for files created in the new
> LibreOffice version.

I don't believe this is something actually useful. If we have a broken default,
then a newly created connection of that type would be broken - so it would be
hardly usable from the beginning. On the other hand, *if* some connection
happens to be already working with this given default (even if we consider it
broken), it doesn't make sense to "fix" it (don't fix what is not broken) with
the risk of making it work unexpectedly for the user (which might have applied
some workarounds expecting the way it worked before). I don't think that it's
more important to be able to silently fix *partially created* connections (I
mean, that apparently users would start such a connection, and then abandon
because of the broken default; or edit it manually in the ODB anyway) than to
have stable connections.

https://lists.freedesktop.org/archives/libreoffice-bugs/2019-March/176631.html
--- Comment #7 from Mike Kaganski ---
... and there could be an option like "Set all inner settings to new defaults"
in the advanced settings dialog.
Comment 6 QA Administrators 2021-03-27 04:07:32 UTC
Dear Mike Kaganski,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug