nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Tweaking the TEXT SEARCH CONFIGURATION with an existing database

Marwane_K_A_

Hi,

We realized we forgot to adjust the TEXT SEARCH CONFIGURATION in PostgreSQL for a Nuxeo database, to make the full text searches accent-insensitive.

We tested the CREATE EXTENSION unaccent; etc. commands on a medium-sized Nuxeo, which worked well except the first login after launching Nuxeo took longer than usual.

I reckon this is more PostgreSQL-related, but does the database have to rebuild the whole index after making changes to this configuration? This could be a problem if we execute the script on our production database, which is much larger than the first one (we don't want to end up with Nuxeo being frozen for... an undefinite amount of time).

Thanks for your advice

Find more posts tagged with

Accepted answers

Florent_Guillau

Nuxeo does not automatically rebuild fulltext indexes when the fulltext configuration changes. The slowdown you're seeing must be coming from somewhere else.

If you changed the fulltext configuration you'll need to reindex everything, the nuxeo-reindex-fulltext addon can do that for you.

All comments

schambon_

The question really is about how/when the Postgres FTS configuration change applies. As far as I can tell the text search configuration is set up in the nx_to_tsvector function, which is used to build the fts index on the fulltext table.

Florent_Guillau

Nuxeo does not automatically rebuild fulltext indexes when the fulltext configuration changes. The slowdown you're seeing must be coming from somewhere else.

If you changed the fulltext configuration you'll need to reindex everything, the nuxeo-reindex-fulltext addon can do that for you.

Marwane_K_A_

Thanks for your answer.

schambon_

The addon works by changing the dc

Florent_Guillau

Yes you're right, in your case if all that changed is the PostgreSQL TEXT SEARCH CONFIGURATION then that would be enough and much more efficient.