EPrints Technical Mailing List Archive

Message: #08366

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] Trying to understand a disaster after a database update

CAUTION: This e-mail originated outside the University of Southampton.

Thanks David for your first (and quick) answer !

To refine further a small detail, I didn't suppress (nor from eprints_field.pl
or the database) the "old" field/metadata, so both of them (the old and the new
ones : both of them are useful in our functional processes, but for distinct
purposes) still exists in the repository schema and in the database structure...

Best regards and thanks for your help
Laurent Cloarec

Le 16/11/2020 à 12:09, David R Newman a écrit :


Hi Laurent,

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 field.

Regards

David Newman

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
"eprint_creators_infoX(eprintid,pos,creators_infoX)"

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
    "eprint_creators_infoY(eprintid,pos,creators_infoY)"
 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&amp;data=04%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C75bd817906824beb8f9008d88a22c536%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411229226700162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bAjKjok8qYjLyZT3EwWbnGC3QkT1EfhqoraZr5O7%2BOA%3D&amp;reserved=0
*** EPrints community wiki:https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&amp;data=04%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C75bd817906824beb8f9008d88a22c536%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411229226700162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fpgN4TlhUm26eMGNPT2UDHC5hnpevQTkrSFy8Q3wzp4%3D&amp;reserved=0


<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2Femail-signature%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&amp;data=04%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C75bd817906824beb8f9008d88a22c536%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411229226700162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fIQVusn8FLciBxFyRXrqX%2B3cInqXv1D0RS2OHgsflg8%3D&amp;reserved=0>
      Virus-free. https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2F&amp;data=04%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C75bd817906824beb8f9008d88a22c536%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411229226700162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vvsU7zC82Xqd0XPFU3qsTXsun%2F4J3myu1dlBPdgH5O4%3D&amp;reserved=0
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2Femail-signature%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&amp;data=04%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C75bd817906824beb8f9008d88a22c536%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411229226700162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fIQVusn8FLciBxFyRXrqX%2B3cInqXv1D0RS2OHgsflg8%3D&amp;reserved=0>


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>