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...
Let's set this to NEW
Hello Mike, Do you think this could become a task for GSOC ?
(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.
Yep, sure, I'm not saying you should mentor it. Do you think it should be discussed in the dev list first ?
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.
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
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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug