I've made a little toolset (https://github.com/cmrd-senya/odb-dev-tools) to inspect how does Libreoffice Base work and I noticed, that even when I just open some form to view it or save the form while not doing any changes in the editor, the changes are still introduced in my file. I think it is a bug, because I don't want the document to be changed without my intention and without a real need. I want changes in the format to be reduced to a required and requested minimum. Create a test document: 1) Create a new HSQLDB document with LO:Base. 2) Add a table with an id and a text columns. 3) Add a form and add a table to view the database table we introduced in the step 2. Save it and close. 4) Open a form for view (not editor) and close it. 5) Save it as test.odb and close. 6) run odb_init on the file to generate a handy git repo (test.odb-dev) to control changes. Scenario 1. Viewing a form. 1) Open a document with LO:Base. 2) Open a form for view and close it. 3) Close the document. 4) In the test.odb-dev repository run odb_update to pull the changes from the document. 5) Check the git diff. The document is changed. Scenario 2. Saving a form with no changes. 1) Open a document with LO:Base. 2) Open a form for edit. You can see that the form can be saved. Save it. 3) Save and close the document. 4) In the test.odb-dev repository run odb_update to pull the changes from the document. 5) Check the git diff. The document is changed (even more than before). The most of the changes are reordering of elements in the XML tree. I think these are absolutely unnecessary. Some changes are dates updates (e.g. in database/properties). These changes are OK. In more complex documents there are more changes, which I can't identify or describe. If you keep repeating the scenarios, you'll keep seeing changes, so there is possibly some random in the process of a document (de)serialization.
Please attach a simple test case. Marking as NEEDINFO - once you attach a simple test case, mark as UNCONFIRMED. Thanks
Created attachment 119316 [details] A fresh document
Created attachment 119317 [details] A document after running scenario 1
Created attachment 119318 [details] A document after running scenario 2
Created attachment 119319 [details] Diff after scenario 1
Created attachment 119320 [details] Diff after scenario 2
I attached documents, produces running my steps I described before. I forgot to mention, I'm using LO 4.2.8.2 from Ubuntu repositories.
I would suggest testing with a currently supported version of LibreOffice. 4.2 has been end of life for some time. 5.0 is currently our main branch and can be installed from a ppa easily: https://launchpad.net/~libreoffice/+archive/ubuntu/ppa 4.2 will not see any further updates and there's a decent chance this isn't an issue in a currently supported version.
@senya : my understanding of this is that we use a Java UNO IO serialize/deserialize object/method/class to retrieve data from the database and then write it back. This is probably why there is no guarantee of ever having an identical file stream on successive loading/closing with a CVS/git/subversion tool, but others more knowledgeable than I am might be able to add something.
Looks like with 5.0 version it behaves better, but I still need research it for a while. There is still an issue - why when I open a form for editing, it shows me changes immediately after form load when I had no chance to introduce them yet? That's wrong, I think. @Alex Thurgood, if I used Libreoffice Base with embedded Firebird DB and with no java machine installed, would it be different?
(In reply to senya from comment #10) > There is still an issue - why when I open a form for editing, it shows me > changes immediately after form load when I had no chance to introduce them > yet? That's wrong, I think. Yes, it is a bug. Old issue, we had it for as long as I remember. I welcome patches :)
(In reply to senya from comment #10) > Looks like with 5.0 version it behaves better, but I still need research it > for a while. > > There is still an issue - why when I open a form for editing, it shows me > changes immediately after form load when I had no chance to introduce them > yet? That's wrong, I think. > > @Alex Thurgood, if I used Libreoffice Base with embedded Firebird DB and > with no java machine installed, would it be different?
(In reply to Alex Thurgood from comment #12) Hi Senya, > > > > @Alex Thurgood, if I used Libreoffice Base with embedded Firebird DB and > > with no java machine installed, would it be different? No idea I'm afraid, I don't know how LibreOffice handles the in process / in memory loading of data from embedded Firebird databases, but I would assume it does so in a similar manner to that used for hsqldb. Note that the wiki page on using version management systems with LO is conspicuously silent on being able to do so with ODB files - from the suggestion made to export to FODT, I would surmise that there is never even any guarantee of being able to consistently manage the other other modules default container-based formats (ODT/ODS/ODP etc) : https://wiki.documentfoundation.org/Libreoffice_and_subversion
That's a shame, because it would be a nice feature to have.
(In reply to Alex Thurgood from comment #13) > (In reply to Alex Thurgood from comment #12) >>> @Alex Thurgood, if I used Libreoffice Base with embedded Firebird DB and >>> with no java machine installed, would it be different? > No idea I'm afraid, I don't know how LibreOffice handles the in process / in > memory loading of data from embedded Firebird databases, but I would assume > it does so in a similar manner to that used for hsqldb. No, not similar to HSQLDB. The HSQLDB integration does an implicit "save" of the odb file on a database commit and shutdown. The firebird integration does not do that.
(In reply to Lionel Elie Mamane from comment #15) > No, not similar to HSQLDB. The HSQLDB integration does an implicit "save" of > the odb file on a database commit and shutdown. The firebird integration > does not do that. Thanks Lionel, good to know. I'd like to either set this to resolved WFM or else confirm as NEW with a changed title that reflects the issue with forms causing a change in the file status, unless you happen to know which old bug that behaviour stems from, in which case I'll mark it DUP.
IMO the issue is muddy. I'm not too happy that embedded HSQLDB does that implicit save, which has been a source of overall brittleness, problems with data corruption, etc. However, I don't think it is a bug that, when a save is done, XML elements are reordered. What senya is encountering is a mismatch between the "document model" and how git sees it. The document model is a *tree*, whereas the order of some children of some nodes is irrelevant; the tree needs to be looked up to isomorphism. What git sees is *text* that is a particular serialisation of it. It does not look "up to isomorphism". Git would consider these three different: <a><b></b></a> <a><b/></a> <a> <b/> <a> But as XML trees, these are *exactly* the same documents. Is it desirable that the serialisation be stable? Yes. Is it a bug if it is not? No. Will I take patches that break nothing else and make the serialisation stable? Yes. Do I think this "serialisation is not stable" state is limited to Base? No. ---> maybe larger discussion within LibreOffice dev. With regards to comment 11, if that bug is not yet reported in this bugzilla, feel free to fork it into a new bug entry (and fix it :)). About scenario 2: * there are some reorderings, see above. * two attributes added: draw:wrap-influence-on-position="once-concurrent" style:flow-with-text="false" yes, that's weird. I would have thought it stems from different LibreOffice versions that did the previous save and the new save, but it seems senya is not changing versions in between the two (the meta:generator is not changing). Don't know. * IsSelectedFrame toggles from false to true: err... don't know * Rsid change: don't know what rsid is. I think a Writer expert would have more clue there. (forms are writer documents)
(In reply to Lionel Elie Mamane from comment #17) > With regards to comment 11, if that bug is not yet reported in this > bugzilla, feel free to fork it into a new bug entry (and fix it :)). > > A quick trawl in BZ didn't bring back anything which struck me as similar, so I'll open a new report for this. As for fixing it, well, a parallel universe and a new lifespan would likely be the only way I'd be able to do that ;-)
(In reply to Lionel Elie Mamane from comment #17) > About scenario 2: > > * there are some reorderings, see above. > > * two attributes added: draw:wrap-influence-on-position="once-concurrent" > style:flow-with-text="false" > > yes, that's weird. I would have thought it stems from different > LibreOffice versions that did the previous save and the new save, but it > seems senya is not changing versions in between the two (the meta:generator > is not changing). Don't know. I was thinking that this might have come about when code changes relative to word wrap of anchored objects were made in Writer, but I don't remember when then happened (4.x something ?)
(In reply to Alex Thurgood from comment #18) > (In reply to Lionel Elie Mamane from comment #17) > > > With regards to comment 11, if that bug is not yet reported in this > > bugzilla, feel free to fork it into a new bug entry (and fix it :)). > > > > > > > A quick trawl in BZ didn't bring back anything which struck me as similar, > so I'll open a new report for this. As for fixing it, well, a parallel > universe and a new lifespan would likely be the only way I'd be able to do > that ;-) Forked as bug 95214
@Miklos : any idea why this might be happening ? - see Lionel's comment 17 for an overview
@Michael : also adding you to CC as Writer expert
Any chance that the added attributes are linked to bug 94274 ?
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Dear senya, 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 http://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 senya, 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