Comment 34 for bug 1251394

Fleshing this out a little more. With an eye toward making data retrieval as flexible as possible, given this data will be used by a variety of clients, here's a breakdown of the current way clients can fetch the display data.

1. metabib.display_entry (table)

Thin table of display entry values.

2. metabib.flat_display_entry (view)

One row per value, combined with data from config.metabib_field and config.display_field_map. Useful for clients that want a list of values and field metadata, like field names and labels.

3. metabib.compressed_display_entry (view)

Same as flat_display_entry, except there's only 1 row per config.display_field_map, i.e. one row per field type. Display entry values are returned as JSON arrays for multi=true fields and JSON scalars for multi=false fields.

4. metabib.wide_display_entry (view)

Analogous to reporter.simple_record.

One row per source (bib record) with a column per well-known field. As with compressed_display_entry, values are JSON-ified and returned as arrays or scalars, depending on multi-ness.

===

Next steps are to flesh out the stock display field configuration data, then finalize the columns for metabib.wide_display_entry.

Still using user/berick/lp1251394-metabib-display-fields-rebase-circa-2.12 for now. Base schema is still out of sync.