[EP-tech] Trying to understand a disaster after a database update
David R Newman
drn at ecs.soton.ac.uk
Mon Nov 16 11:09:11 GMT 2020
So to confirm: Are there are no records in the eprint database table or
you just don't see any records when you look at the Manage Deposits page
in the repository? When you ran recommit at the end of your set of
instructions. How long did this take to run and how many record did you
have before you started this whole process? If it took quite a long
time then it suggests some how the recommit process caused you problem.
However, if it ran quickly this suggests you eprint records were already
deleted or broken so could not be displayed in the Manage Deposits page.
As a general comment on your solution. I would have not dumped out and
reimported database tables. I would have created a rule (block of code)
in your archive's cfg/cfg.d/eprint_fields_automatic.pl to map (probably
just copy) the old field to new field. You would have still had to have
the old field defined in eprint_fields.pl but as long as you had removed
the old field from the eprint workflow and any other config files
(except eprint_fields_automatic.pl and eprint_fields.pl) it should not
be editable, or visible to non-logged in users. You would then need to
run epadmin recommit like you did in your original instructions and once
this completed you could remove (probably best to comment out)
references to the old field and the rule to map the old field to the new
On 16/11/2020 10:49, Laurent Cloarec via Eprints-tech wrote:
> *CAUTION:* This e-mail originated outside the University of Southampton.
> Hello everyone
> The initial problem : many (about 1,000) metadata values entered by
> archive editors in a non appropriate field (used in parallel for
> another purpose by another import mechanism), let's say "infoX". Into
> the database, this information was stored in a table looking like
> The solution employed :
> 1. create a new metadata/field (let's say "infoY") among the creators
> metadata (with "eprints_fields.pl") and update the database
> structure in consequence => creation of a new table
> 2. backup (SQL values dump) the important values previously entered
> and stored into the "eprint_creators_infoX" table;
> 3. from this backup, create a new SQL file where the "infoX" column
> name is replaced by "infoY";
> 4. import these values into the new table ""eprint_creators_infoY";
> 5. delete the previously entered value from "eprint_creators_infoX"
> table (/there was an objective criteria to distinguish the entered
> from the imported values/);
> 6. run "bin/epdamin recommit <archivename> eprint"
> The disaster/issue that happened : all the records from "eprint" main
> table have been deleted, and the archive/repository consequently
> appears as empty!!!
> Could someone explain this???
> Best regards
> Laurent Cloarec
> Service Commun de la Documentation - Service du Numérique Documentaire
> Université Toulouse 1 Capitole
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=04%7C01%7C%7C4797964720bc4a6354e208d88a200e54%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411217564440754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=USzk7ITZuiid7KoSQZrFOMFmjyQTafqsb2u%2Bu399zNQ%3D&reserved=0
> *** EPrints community wiki: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&data=04%7C01%7C%7C4797964720bc4a6354e208d88a200e54%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411217564440754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f%2FxonlUCldTRxyZbK7EvgnTPW5LMhUVzgIVoQFUAoOY%3D&reserved=0
This email has been checked for viruses by AVG.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Eprints-tech