Comment 17 for bug 1849212

I suppose I really should spell out my concerns (and solicit feedback, please make suggestions if you have them!) for everyone here so no one has to look through IRC logs. :)

Currently the feature makes use of a facet that allows users to limit searches to "In Course Reserves" / "Not in Course Reserves." I like this ability but the way facets are implemented generally requires that there be something about (and also to my recollection, *in*) the marc record that the re-/ingest system can grab a hold of. To implement this facet a number of changes had to be made:
1. A new config.metabib_class was added: "Boolean Facet"
2. Used by a new field in config.metabib_field: "On Reserve"
3. The t/f values are only in metabib.facet_entry so the metabib.reingest_metabib_field function requires special casing to avoid Postgres errors when trying to delete from the missing metabib.boolean_facet_entry table.
4. The way this facet is updated is by special purpose triggers on biblio.record_entry and asset.course_module_course_materials

I have issues with most stops along the way:
1. The current metabib schema is setup to be a fairly generic mechanism (A single field may be used for any combination of search / browse / facet / display) and this change introduces an extremely specific change at the base level that is only used for facets
2. (not really an issue on its own; merely a side effect of 1.)
3. This would start a precedent of having to specifically check table names in triggers that are otherwise wholly generic. Once we have one "IF table_name ='blah' THEN RETURN" it's only a matter of time before it becomes "IF table_name IN ('','','',) OR ..." We need to clean up and refactor several situations like this as-is; we shouldn't add more if there's any way around it.
4. It's entirely possible that there will be some triggers along the way when implementing this type of facet but we need to try to a., have fewer triggers on bre rather than more, and b., avoid very specific triggers when at all possible.

I'm sure there's a reasonable way to accommodate this t/f and other non-marc-based facets but I don't believe such a thing exists currently in Evergreen today. Does anyone have thoughts on how to handle this in a fairly general way? Ideally in the end users would be able to arrange them however they like within the facet order in templates/opac/parts/config.tt2.