[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Laurent,

Obviously, if you want to retain the old field, ignore my advice about 
removing this field in the workflow and other config files. I think I 
read the inappropriate as applying to the field as a whole rather than 
the import data being added to this field when it was not appropriate 
and a new field with a more appropriate name would be better.? If you 
write a "rule" then you could get the is unset the old field whilst 
setting the new field.? You could also have some conditional statement 
to only move the value when it matches certain patterns, so it only 
moves the value to the new field when it is appropriate.


David Newman

On 16/11/2020 11:28, Laurent Cloarec wrote:
> 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%7C%7C6f538a8240004a0d166b08d88a23fe17%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411234471105962%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=xVY3ugx9amlYgJgcF%2BURKZkaDYwZhhS1BUnNs5fH5yk%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%7C%7C6f538a8240004a0d166b08d88a23fe17%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411234471115914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=aiSc1Z0i7aye1dup8sTOgBRErivr8X0wvDzfu9%2FX1Gs%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%7C%7C6f538a8240004a0d166b08d88a23fe17%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411234471115914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=xye0O%2BVt02KzsJW2sGg%2F11%2FmA2iBLcX8gZTyqVdxsvE%3D&amp;reserved=0> 
>> ????? Virus-free. 
>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2F&amp;data=04%7C01%7C%7C6f538a8240004a0d166b08d88a23fe17%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411234471115914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZTQUDUD5FfmdRkZPm%2F1U%2FRKMEvZjMBx9vpIZvRLmWRg%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%7C%7C6f538a8240004a0d166b08d88a23fe17%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637411234471115914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=xye0O%2BVt02KzsJW2sGg%2F11%2FmA2iBLcX8gZTyqVdxsvE%3D&amp;reserved=0> 
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

This email has been checked for viruses by AVG.