[OPEN-ILS-GENERAL] EG 2.0: problem Marc2bre - Global Flags "Maintain 001-003-035 according MARC" and "TCN=Internal ID"

[Repke de Vries]

Exactly right Dan !

And there is a lesson or two here: 

- you are explaining what some of the calling parameters of importing scripts actually do; this is much needed: even reading these script's code this is not always clear or evident; and the scripts don't have a --h for Help parameter either (I know: building in Help information means even more work);
without adequate information people like me busy migrating or new comers evaluating Evergreen, blindly copy existing examples of calling parameter values - and easily get incomprehensible results or draw wrong conclusions on Evergreen's strengths and weaknesses;
I guess this type of "what does this script actually do" documenting and interviewing the developers if need be, is already going on in Evergreen DIG context - and the results are showing for both EG 1.6 and 2.0: http://docs.evergreen-ils.org/

- however: your explanations also reveal something else: a kind of "scenarios of use" where decisions upstream calling importing scripts for bibliographic and holdings data in certain ways (like the --idfield) influence everything that happens downstream big time - even to the extent that Global Flag settings are seemingly ignored; 
another example is holdings data where the 852 $b and $c  would get ignored if not downstream the Evergreen Organisational Structure definition and the Copy Location definitions are set correctly;

and these "scenario's of use"  (which are close to what you call "behaviour that is expected from Evergreen" and to your question "is this what you are looking for?") we presently do *not* have in our EG DIG documentation: we  document  *per* script,  *per* list of settings, *per* whatever  but don't explain how it all fits together, how what we want to happen downstream needs very particular measures to be taken upstream. 

The Staff Client (the GUI as you call it) has such "scenarios of use", such assumptions built in - like when importing bib records and the way this works together with Global Flag and other Settings; this Staff Client behaviour is not explicitly   documented however (yet).

So: yes - this is what IISH is looking for given it's "scenario of use" but I also realise that there are other such scenario's migrating with particular bibliographic and holdings data  and that the official EG documentation could be helped very much with explicit scenario's: if you want this and these our your data, take these measures and call your scripts in such and such ways. Will contribute with IISH's. 

Is this "scenario of use" an approach appealing to others migrating or evaluating as well? 

Thanks ! Repke 

Op 5 mrt 2011, om 04:57 heeft Dan Scott het volgende geschreven:

> On Fri, Mar 04, 2011 at 10:00:02PM +0100, Repke de Vries wrote:
>> Apologies Dan for the long gap discussing this - and thanks for your fix (part of the 2.0.2 release) that makes the Global Flag "Cat: Use internal ID for TCN value"  when set to TRUE, have the same effect for command line importing bib records as it already had  for importing through the GUI. 
>> 
>> However:  also the other Global Flag "Maintain 001-003-035 according MARC"  when set to TRUE,  behaves differently when importing bib records from the command line then through the GUI:
>> 
>> - through the GUI  the Control Number in the imported bib record's 001 field gets pushed to the 035 as expected and the 001 receives the Evergreen Internal Record ID etc.; and because of the Global Flag "Cat: Use Internal ID for TCN Value" the TCN follows this Internal Record ID 
>> - importing from the command line the Global Flag setting is ignored however and the Control Number in the imported bib record's 001 field becomes the new Evergreen Record ID;  the TCN also ignores it's Global Flag Setting -  this latter behaviour has been fixed now (as I understand it)
> 
> I think there's a misunderstanding here. The --idfield parameter says
> "Set the internal record ID to the value of (whatever field --idfield
> points to)" - which describes the behaviour you're seeing, I think.
> 
> If you want to disregard the existing 001 value in the records that
> you're importing, and just use whatever Evergreen gives you, you can
> import your records as follows:
> 
> marc2bre.pl input.mrc | pg_loader.pl -or bre -a bre
> 
> If you're importing from MARC21XML, you'll need to add the "--marctype
> XML" flag to marc2bre.pl, but you have that part sorted out already.
> Just drop the --idfield (and --idsubfield) flags entirely if you don't
> care about them. The part to focus on is the "-a bre" flag from
> pg_loader.pl; it says "let the database assign a value for this object".
> So pg_loader.pl doesn't assign any value to the "id" column of
> biblio.record_entry, in this case; the column isn't specified in the
> COPY command and the database automatically assigns the next value in
> its sequence for the biblio.record_entry.id column. And that, in turn,
> will ensure that the 001 gets populated with that record ID and the old
> 001 gets pushed to the 035, etc.
> 
> I think that's what you're looking for?