Gramps AIO64-5.2.2-r1-f905d14 @Windows 11 Pro 24H2
Gramps 6.0.6 @Linux Mint 22.3 - Cinnamon 64-bit @VMware® Workstation 17.6.4 Pro @Windows 11 Pro 24H2
I installed Gramps version 6.0.6 a few days ago on a VM to migrate from version 5 to version 6 and imported a version 5 backup into the version 6 database. In doing so, I didn’t pay attention to the identifier size settings (I%04d, …). I worked a bit before realizing it: I added a citation, some individuals, some events, and changed the type of a note in the version 6 database.
Then I realized that the identifiers hadn’t been imported—or created after the import—with the correct size. I changed the identifier size in the preferences (I%05d, …), made a backup, and ran the renumbering. I wasn’t happy with the result because instead of adding a zero, it renumbered everything.
So I decided to create a new database and re-import my V5 backup into a second V6 database. To my surprise, in addition to seeing that the identifiers were correct again, the records I had created or modified in the first V6 database were already present in the second one, even though they weren’t in the V5 backup. Even the modification times for these records were those of the first V6 database. I had planned to recreate them, but not for them to end up there all alone, without any action on my part!
This makes me wonder if there might be a major caching issue in V6?
The 1st part seems more like an Import issue. Where Gramps preserves Handles but does not preserve the IDs of an imported XML. I believe that the previous behavior was to use the ID if (and only if) the ID wasn’t already in use.
Identified earlier that import also does not seem to preserve any manual re-ordering of Families, Events or Children.
The problem isn’t with the import itself (or the IDs stuff which is just here for the context), but with the existence of records in V6 DB #2 that aren’t in the imported file but in the V6 DB #1 I worked with just before that import into the new V6 DB #2
Could you try the manual “Make Backup” and verify if the problem is the same?
I am wondering if the automatic backup did not trigger when expected after making changes. (The “no backup unless changes committed” was a recent evolution to reduce unnecessary backup file creation.)
2nd import from a manual V5 backup into V6 DB #3:the issue isn’t here anymore. But, 15 minutes have passed since my changes in V6 DB #1, while the import into #2 took place one or two minutes after my changes in #1.
The timer might be the issue there. I don’t trust the Export (since there might be filtering) or the automated backup (due the timer and caching trigger guard). I consider the automated backup to simply be 'safety; when I’m being too absent-minded to follow a good backup regimen.
This is intricate enough that the diagnostics need to go beyond observation of behavior and deduction. I think it needs a developer to see what is happening with the backup process or code.
Yes ! But it’s not a loss of data, but excess data ^^
I just did another test: I created a DB #4 and imported the automatic backup file from V5 back into it. Frankly, I don’t understand it at all. The records created in V6 DB #1 are there again!
V6 DB #1 from a V5 automated backup file - that V6 DB #1 state is after modifications and renumbering - notice to the Done - Fait - note type and its ID:
V6 DB #2 from the same automated backup file than V6 DB #1 - the note ID is the ID from V5 backup but the note type is the type from V6 DB #1, notice the lock on that note coming from V6 DB #1 too:
