SPIKE: Design approach for differentiating incoming MARC Bibs that should/shouldn't be saved in SRS

Problem definition:

We don’t have an explicit action to save the SRS MARC record, it is implicit and happens (almost… we already have a couple of exceptional cases, which were added later as “bug fixes”) for each incoming file. When it was designed we thought of an incoming file as a new and valid record that should be saved prior to any other actions and serve as a single source of truth. In fact, what we have now - there are indeed records that are coming and should be saved in SRS and referenced by other entities that are derived from it. However, there are also multiple use cases (usually some kind of updates or creates on Holdings and/or Item), where incoming MARC record is considered to be disposable, it might contain only partial data, and if we save it we end up either with lost data (when original record is overridden) or with messed up links to corresponding inventory entities (when we save the record as new one)

Notes:

• Consider making Create/Update SRS MARC Bib explicit - a separate step in the profile
• Alternatively some kind of a check box should be added when profile is constructed specifying whether MARC Bib is supposed to be saved or not
• Maybe initial saving of incoming MARC Bibs is not necessary, it should be a part of Create Instance (or maybe other scenarios). Might help in eliminating (at least partially) post-processing logic for Instance creation - all ids will be generated and assigned, 001, 003 and 035 handling will have to move to mod-inventory
• Need to clarify the situation with DI logs - if we do not save the incoming MARC Bib, we won't be able to display the MARC json