[OPEN-ILS-DEV] config.internal_flag vs. config.global_flag

[Mike Rylander]

On Mon, Jul 12, 2010 at 4:53 AM, Dan Scott <dan at coffeecode.net> wrote:
> I'm curious about the difference in the intended uses of the
> config.internal_flag table vs. the config.global_flag table in trunk.
>
>  * config.global_flag inherits from config.internal_flag and adds a
> TEXT column for labels
>  * values in config.global_flag are exposed via a Dojo configuration
> interface
>
> Following are the current config.internal_flag values:
>
>  ('ingest.metarecord_mapping.skip_on_insert');
>  ('ingest.reingest.force_on_same_marc');
>  ('ingest.disable_located_uri');
>  ('ingest.disable_metabib_full_rec');
>  ('ingest.disable_metabib_rec_descriptor');
>  ('ingest.disable_metabib_field_entry');
>
> It looks like these internal flags are primarily intended to enable an
> admin to speed up a bulk ingest operation by enabling the database to
> load the records without firing all of the ingest triggers (no doubt to
> be followed by turning all of the ingest triggers back on and forcing
> the records to be ingested once the database is loaded).
>
> If these are flags that are intended to be used by humans at some point,
> shouldn't we just make them global flags so that their values can be
> easily inspected and some context for their use provided by the label
> field? I understand that the wrong setting for these flags could result
> in significant problems, but we already give people plenty of means to
> misconfigure their system.
>

The think that at least some of these can reasonable be exposed.  In particular:

 * 'ingest.reingest.force_on_same_marc'
 * 'ingest.disable_located_uri'

are good candidates IMO.  I think I could be convinced that
'ingest.metarecord_mapping.skip_on_insert' should be included in
global_flags as well.  The others ... I'm significantly less
comfortable with those.  The effects of those can really be had by
simply disabling the ingest trigger altogether, and that would provide
a bigger speed increase to boot.

I'll follow consensus if others want to weigh in, but IMO the size of
the foot-gun that 'ingest.disable_metabib_full_rec',
'ingest.disable_metabib_rec_descriptor', and
'ingest.disable_metabib_field_entry' present is quite a bit bigger
than the others.  Or, argued another way, I'd rather we get a feel for
how we expect global_flags to act (see it in deployment, find out what
is useful in practice), and whether global_flags is missing some knobs
that really are useful, before adding the most dangerous ones.

> (Aside: if settings-tester.pl is still considered a useful tool for
> debugging system problems, it might make sense to dump the contents of
> the config.internal_flag & other settings tables like OU settings,
> etc... just a thought).

And a good one.  Agreed!

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com