With Gramps ID formats set [under preferences] to 5 [other than events, at 6].
After converting a large tree from BSDDB to SQLITE, an object that previously had the ID e.g. N01876 [consistent with a Gramps ID format setting for Notes as N&05d] appears with an ID of N1876.
In the new SQLITE tree, Events all appear as if the ID format setting was E%04d [when in fact the current setting was and is E%06d], unless the numerical value of the object ID is > 9999.
In other words, leading zeroes in the ID of very many objects have been deleted.
This has serious impacts on custom filters, and defeats the entire purpose of having a preference setting for ID formats.
Is this a bug?
If a user runs the “Reorder Gramps IDs” tool with the “keep” option, does this reliably restore the leading zeroes to the preferences settings, without changing the numerical ID of any object?
But even if it does, why does a user who already has the ID formats set to their preferred values, need to apply an additional tool to implement them in order to convert a tree?
Sorry, that was a typo here on Discourse, NOT in my Gramps ID format settings, which all use %.
I have used the current settings for all my databases for a very long time, and they were …%05d for all objects other than the …%06d for events at the time of conversion from BSDDB to SQLITE, but appear to have been completely ignored for the conversion.
I cannot use SQLITE for any of my databases unless & until I can be certain the source ID formats will be unchanged.
To change the zero (0) padding in existing Id’s, use the Reorder Gramps IDs tool. Set the size of the padding for each database; %04d, %05d, %06d… You can then run the tool increasing the digital padding.
Do NOT select the Change option. This option will renumber your databases removing gaps in the sequencing (deleted and merged records). The Keep option is to maintain special IDs utilized by internet place download/merge operations or IDs that do not follow the Gramps ID format.
But as always before undertaking a batch edit make sure to have a backup of your database. There is no undo option so if things do not go as expected you can return to the previous status quo.
If you run the tool without selecting the “change” option nothing happens whatsoever.
In this situation you would have to run it WITH the change option, AND with the “keep” option ALSO enabled.
But I am not yet confident that the result is identical in both ID format and numerical value for every object in the original database.
My original question was why does the conversion of a BSDDB database to SQLITE not respect the then-current Gramps ID format settings? Even if the tool works, a user should not have to apply a second step with a fiddly tool to produce a converted database which is identical to its source other than for its backend.
It looks to me like a bug, but I am happy to be persuaded otherwise.
I just tested this on a side database increasing the padding to %07d. Without selecting ‘Change’ all existing Ids received a new leading zero while retaining their existing number.
5.1.5 with SQLite.
The only thing I can think of is that if you did the change from BSDDB to SQLite at the same time you moved up to 5.1. If you did the clean install the defaults for Id formatting would have been %04d with the new gramps.ini file. This might have had an effect on the database conversion.
About once a month I use the tool using the ‘Change’ option selected and the ‘Keep’ option deselected. This reorders my database sequencing after merges and deletes as I continue to document my database. I do not use any custom Id’s.
I have had the same Gramps ID format settings – all a longer string than the default 4 – for many years through succcessive Gramps versions. Apart from lengthening all ID strings, I otherwise have no “custom” IDs.
I am talking about a conversion made from BSDDB to SQLITE just in the last few days.
The ID settings are first on the list of things I check after any Gramps upgrade. So the default settings had been explicitly overridden by my own settings well prior to conversion.
It is clear that the conversion does not respect a user’s Gramps ID format settings. The database I converted already contained only my specified ID formats, and the conversion was undertaken on a Gramps install that was already correctly set to the specified ID format settings.
The test you have run using the “Reorder Gramps IDs” tool, does, I now realise, enable restoration of leading zeroes. But it is extremely cumbersome and counter-intuitive to achieve that outcome. It is counter-intuitive because in this case what is called for is reformatting, NOT reordering. And despite “change” needing to be UNselected, change IS required, but of format (only) and definitely not of number. It only works for this particular task if there is a check against the relevant type(s) in the Objects column, and NO check in either the “Change” or the “Keep” columns, but it is not at all obvious in the UI when it is in that state that anything will happen, but indeed you may eventually notice that the “OK” button is not greyed out. After the tool completes, the formats appear to have been applied correctly, with the correct string lengths, and with leading zeroes returned to those which originally had them. On my investigations so far, it appears that object numbering is preserved, but further testing is going to be needed to verify that.
My original problem remains: Why does a user need to apply a fiddly tool, in a messy two-stage process, to achieve correct conversion of a database? Why is it not a bug that the conversion is clearly not consistent with the ID formats of the source AND the user settings? Why does the conversion assume the Gramps default ID formats when there are non-default user preferences already set?
I have several BSDDB databases. I tried to convert them to SQLite.
I did not reproduce your problem as it works correctly for me on linux.
The new SQLite database get the new format for all objects (notes, events,…)