Rebuilding the FT Index

Good morning everyone. @DavidMStraub has been very helpful with this issue privately, but I am opening this up to the greater community.


My mother had done extensive research on our family history, but she divided the research into different files for different branches. With her passing earlier this year, I have begun the process of re-integrating the trees and publishing them on the World Wide Web. After the initial release several weeks ago focused on my maternal grandfather’s familey (Piechotka), I have integrated several more trees together on my local copy, which is now much larger (20,000+ individuals).

The current problem

I shut down the web server, (which is to say grampsweb) and transferred the files up and restarted things. Now when I try to open the server, I cannot set a home person – nothing is listed. In provate conversations with David, we agree that the Full Text index needs to be rebuilt, but this was failing on that box, so I am trying on copy of the tree on one of my local Ubuntu boxes. When I initiate the rebuild, well, it’s not happy:

docker-compose run grampsweb python3 -m gramps_webapi --config /app/config/config.cfg search --tree 2d6f4154-1385-45ff-823d-5f6ac180133e index-full
Creating grampsweb_grampsweb_run ... done
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
ERROR [alembic.util.messaging] Can't locate revision identified by '22c8d1fba959'
  FAILED: Can't locate revision identified by '22c8d1fba959'
Traceback (most recent call last):
  File "/usr/lib/python3.9/", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.9/", line 87, in _run_code
    exec(code, run_globals)
  File "/app/src/gramps_webapi/", line 199, in <module>
  File "/usr/local/lib/python3.9/dist-packages/click/", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/click/", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/dist-packages/click/", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/dist-packages/click/", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/dist-packages/click/", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/dist-packages/click/", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/click/", line 26, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/app/src/gramps_webapi/", line 119, in migrate_db, env=env, check=True)
  File "/usr/lib/python3.9/", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'alembic', 'upgrade', 'head']' returned non-zero exit status 255.

Thoughts folks? Buehler? Buehler?

1 Like

(We now return you to consolidating the several hundred individual place object, all labelled “Brooklyn”… :smiley: )

If thats a real task, please look at the MultiMerge add-on from the Isotammi project.

Their automerge in the Place category variant of that Gramplet is a huge time-saver. (I wish there was similar automated duplicate consolidation in the other Category records!

Hi @dmgursky, the error indicates the user database is not found. Have you copied it as well?

That user database migrations are run automatically is a feature of the default docker image by the way, it’s not the reindexing script. You can try adding docker-compose run --entrypoint [] grampsweb ... to skip the entrypoint that does this. Then it might work without the user database.

So for those of you in the listening audience, here is my response to David on our private thread, for completeness:

Close enough for government work.

The issue wasn’t that it couldn’t find the User database (/var/lib/docker/volume/grampsweb_gramps+_user/_data, or something akin to that), but there was a mismatch in values between the user database on the servers.

I pulled a copy of the user.sqlite down from my production server to my local server when I pulled the master database, but the value pf version_num in the alembic_version table was different in the two. Being a good QA person, I had made a backup of the original user.sqlite on my local box, so I simply updated the value to match and everything ran fine.

The index completed in less than the time it took to write this response. G-d willing everything works when I put this back on the production box. Cross your fingers…

1 Like