2013/3/16 Tim Lyons <guy.linton@...>
> bdbversion.txt is already written in gramps34, it is just that it is not
> in the right way.
> (I have looked at this myself, and done some prototype work, but not the
> full fix).
> I believe this needs to be fixed in gramps34 as well as 40 and trunk,
> because there will still be people upgrading from even earlier versions of
> Gramps to gramps34, and also, it will apply if the bsddb version is
> underneath any version of Gramps (by some upgrade to the platform).
> I have now raised
> http://www.gramps-project.org/bugs/view.php?id=6483 Listing the Family
> can corrupt them
> http://www.gramps-project.org/bugs/view.php?id=6529 Cancelling database
> upgrade can corrupt the database
> I suggest the following changes to gramps34, gramps40 and trunk:
> (1) Change src/cli/clidbman.py get_dbdir_summary()
> (a) return (count, bsdbdversion, schemaversion)
> (b) On entry open bdbversion.txt. If the file is absent or not the
> current version of bsddb return ("Unknown", "Unknown", "Unknown") without
> touching the database.
> (2) Change src/cli/clidbman.py family_tree_summary() to output both bsddb
> version and schema version (note that at present, "db version" means the
> schema version, not the [bsd]db version).
> (3) Change src/gen/db/write.py __check_db_version()
> (a) Open bdbversion.txt
> (b) If bsddbversion is the current version, return.
> (c) If the file is absent, run a Question dialogue explaining that the
> version of the database could not be determined and asking whether you want
> to try to open the database.
> (d) If the bsddb is going to be upgraded run a question dialogue
> explaining that the database will be upgraded.
> (e) If the user answers yes to the dialogues, create a zip file in
> .gramps, named <path_name from NAME_FILE>_<date>_<time> containing all the
> database files. Then return.
> (f) if the user answers no to the dialogue, raise an exception.
> (g) If the bsddb is going to be a downgrade, raise the exception as at
> I suggest the output to a zip file, because at least that way, if there are
> problems, the user has some chance of having a 'backup' file that could be
> used to recover the data.
> Note, I think some of the errors in dbloader.py read_file may no longer be
> raised. I have not checked things like import and open in cli to see
> there may be other places that need to be fixed.
> I think these are all bugs (rather than feature requests) except for
> changing the family tree summary, but I hope you will agree that this is a
> necessary change so that users can understand what is happening.
I agree to this, although too many dialogs is not very nice. Probably3 c
and d above can be rolled in one dialog.
I don't think the bug should hold up release. Also,, changes like this need
some testing, so if we do before release, release must be postponed. So I
suggest to put it on next release, and that we do that release together
Now we need a release to have plugins working again.
Tim, do you have time to do these fixes the coming month?
> View this message in context:
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> Gramps-devel mailing list