[OPEN-ILS-GENERAL] EG 2.0: problem Marc2bre - Global Flags "Maintain 001-003-035 according MARC" and "TCN=Internal ID"
Dan Scott
dan at coffeecode.net
Sun Mar 6 09:14:37 EST 2011
On Sat, Mar 05, 2011 at 07:17:11PM +0100, Repke de Vries wrote:
> 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);
Yes, these particular scripts date back to the dawn of Evergreen time.
More recent scripts generally include embedded help and examples,
thankfully (the authority_control_fields.pl script, for examples,
contains full NAME/SYNOPSIS/DESCRIPTION/OPTIONS/EXAMPLES standard in man
pages and recommended by perldoc).
In the case of pg_loader.pl and the --autoprimary/-a --order/-o flags,
it's not hard to add basic help for the flags alone. It's harder making
those options make sense in the bigger picture, though, within the
context of the script. ("What do you mean by 'autoprimary'? Oh, okay,
can you explain how database sequences work? And what impact does this
have if you have this global flag set a certain way?").
So, while I agree that it would be a desirable goal to have Evergreen's
core scripts provide basic help, I also agree with the conclusion that
you draw later on that adding scenarios / concepts / workflows in
context in the documentation would be a good goal as well
(particularly to enable the scripts to point to that broader contextual
information).
> - 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;
At the risk of repeating myself, and possibly I'm not understanding you
here, but the global flag settings are _not_ ignored when you use the
scripts. The goal of the global flag settings in this case is to get the
record ID (biblio.record_entry.id in the database) equal to the value of
the 001 field, which will in turn be equal to the value of the TCN
(biblio.record_entry.tcn_value).
I tried to say that if you use marc2bre.pl --idfield 001 and the 001
field contains numeric IDs, the script will force the internal record ID
to be what it finds in the 001, and the record that ends up in Evergreen
will have biblio.record_entry.id == the 001 == the TCN. So the global
flag requirement is satisfied, and there's no reason for the 001 to get
moved into the 035 because it's already the correct value.
Using the "pg_loader.pl -a bre" flag says "use an automatically assigned
value for the primary ID of the bre (biblio.record_entry) object", which
will just grab a sequential value for biblio.record_entry.id of the
incoming bib record and that (unless it happens to match the existing
001) will cause the existing 001 to get moved to the 035 so that the
biblio.record_entry.id == the 001 == the TCN.
> 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;
Hmm, is this documented or reported in a bug anywhere?
> 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?
+1
This sort of conceptual documentation provides the "why" for the "how"
(and offers guidance when a given step requires you to make a choice).
More information about the Open-ils-general
mailing list