Difference between revisions of "Adding a Field to a Live Repository"
(Brought the most recent documentation to the top, so the warnings about needing to modify the SQL tables was clearly referring to 3.0 and not 3.3+.) |
m (Line return adjustments.) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 23: | Line 23: | ||
'yes', | 'yes', | ||
'no', | 'no', | ||
| − | ' | + | 'partial', |
], | ], | ||
input_rows => 1, | input_rows => 1, | ||
| Line 34: | Line 34: | ||
'yes', | 'yes', | ||
'no', | 'no', | ||
| − | ' | + | 'partial', |
], | ], | ||
input_rows => 1, | input_rows => 1, | ||
| Line 46: | Line 46: | ||
| − | Then, once you have added your new field definitions to the appropriate configuration file you can run ''update'' via [[API:bin/epadmin|epadmin]] from the shell: | + | Then, once you have added your new field definitions to the appropriate configuration file you can run ''update'' via [[API:bin/epadmin|epadmin]] from the shell. |
| + | |||
| + | |||
| + | You can begin with a dry run to see what would happen: | ||
| + | |||
| + | ./bin/epadmin update_dry_run ARCHIVEID | ||
| + | |||
| + | Then once confident proceed for real: | ||
./bin/epadmin update ARCHIVEID | ./bin/epadmin update ARCHIVEID | ||
| + | |||
Latest revision as of 17:24, 17 July 2023
EPrints 3.3+
Follow the instructions as you would for HOW TO: Add a New Field.
As described there, you define your new fields in...
/opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/eprint_fields.plfor EPrint-level metadata,/opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/document_fields.plfor document-level metadata (this file doesn't exist by default, but is honoured),- and
/opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/user_fields.plfor user metadata, etc etc.
Since a repository's eprint_fields.pl will override a flavour's eprint_fields.pl based on them both having the same file name, should you only wish to add to a flavour's fields rather than replace them, you may prefer to give your archive's local version a file name such as eprint_fields_local.pl, and then inside have only your new field(s):
push @{$c->{fields}->{eprint}},
{
name => 'my_first_new_field',
type => 'set',
options => [
'yes',
'no',
'partial',
],
input_rows => 1,
},
{
name => 'my_second_new_field',
type => 'set',
options => [
'yes',
'no',
'partial',
],
input_rows => 1,
},
;
Simply make sure your push, is adding your field to the correct dataset you wish to add fields to - in this case an eprint dataset.
Then, once you have added your new field definitions to the appropriate configuration file you can run update via epadmin from the shell.
You can begin with a dry run to see what would happen:
./bin/epadmin update_dry_run ARCHIVEID
Then once confident proceed for real:
./bin/epadmin update ARCHIVEID
EPrints 3.1+
EPrint 3.3's update is a synonym of the update_database_structure method available from Eprints 3.1+:
./bin/epadmin update_database_structure ARCHIVEID
EPrints 3.0
To add a field to a live eprints archive in Eprints 3.0 you have to modify the SQL tables. Before you start this, you may wish to BackupTheDatabase.
- Add the new columns to the appropriate tables. There are no longer four separate tables for eprints as there were in EP2 (
archive,bufferetc), so it's simpler.- For a field defined in
eprint_fields.pl, the tables areeprintandeprint__ordervalues_en(replacingenwith your language as required). - For a field defined in
document_fields.pl, you wantdocumentanddocument__ordervalues_en. - And so on...
- For a field defined in
- The column types are the same as for EP2, ie in
eprintyou want a type appropriate to the type of your field exactly as described in the Recipe for EP2, while ineprint__ordervalues_enyou wanttextirrespective of your field type.
EPrints 2.x
See historical versions of this wiki page.
