Search Auto suggest not removing deleted bibs

[Steve Callender]

I've tested this in 3.0.3.

When a bib record is deleted, it's auto-suggest values are remaining. This causes auto-suggest to continue displaying the value but clicking on it will take you to 0 records.

Doing some testing, I can see that when deleting a bib, the mapping is removed from metabib.browse_entry_def_map but the actual entry that is used for the display remains in metabib.browse_entry.

I did a simple query to identify all problem records,

select count(*) from metabib.browse_entry where id not in (select entry from metabib.browse_entry_def_map);

I believe that when deleting a bib record, both entries should be removed. The mapping and the entry itself. It does not look like Evergreen shares entries among multiple bib records so it should just be removed.

Steve

[Steve Callender (stevecallender)]

So a little hiccup to this, is it looks like authority entries will not have a corresponding def_map entry, so just doing a blanket test for any browse_entrys that do not have def_maps is not going to work if you are using authorities.

[Mike Rylander (mrylander)]

And, just to clarify, multiple bibs will use a single (unique) browse entry. That table is a list of unique strings, and the mapping table(s) identify which records use each and how each is used.

[Josh Stompro (u-launchpad-stompro-org)]

What are people currently using to clean these entries up?

I've been using this query during upgrades to reset things, but I'm guessing this isn't quite right based on the note bout authorities.

:~/Evergreen/Open-ILS/src/sql/Pg/larl-upgrade/cleanup-scripts$ cat clean_up_metabib_browse.sql
DELETE FROM metabib.browse_entry WHERE id IN (
    SELECT DISTINCT(entry.id)
    FROM metabib.browse_entry entry
        LEFT JOIN metabib.browse_entry_def_map map
            ON (map.entry = entry.id)
        LEFT JOIN metabib.browse_entry_simple_heading_map hmap
            ON (hmap.entry = entry.id)
    WHERE map.id IS NULL AND hmap.id IS NULL
);