⧼vector-jumptocontent⧽

Adding a Field to a Live Repository: Difference between revisions

From EPrints Documentation
Kgoetz (talk | contribs)
m appears out of date and needing an update
Ajm (talk | contribs)
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+.
Line 3: Line 3:
[[Category: Out of Date]]
[[Category: Out of Date]]


To add a field to a live eprints archive you have to modify the SQL tables.
=== EPrints 3.3+ ===


Before you start this you may wish to BackupTheDatabase.
Follow the instructions as you would for [[HOW TO: Add a New Field]].


This assumes you are adding a field to the "eprint" fields, not the "user" fields. If you are changing "user" then anywhere we have 4 actions, one for each of buffer, deletion, archive and inbox, you instead need a single action for "users".
As described there, you define your new fields in...
* <code>/opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/eprint_fields.pl</code> for EPrint-level metadata,
* <code>/opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/document_fields.pl</code> for document-level metadata (this file doesn't exist by default, but is honoured),  
* and <code>/opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/user_fields.pl</code> for user metadata, etc etc.


Adding fields of type "name" is beyond the scope of these instructions.


== Recipe (for Eprints 3.x) ==
Since a repository's <code>eprint_fields.pl</code> will override a flavour's <code>eprint_fields.pl</code> 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 <code>eprint_fields_local.pl</code>, and then inside have only your new field(s):


This is much the same as for Eprints 2.x except that the names have been changed to protect the innocent.
push @{$c->{fields}->{eprint}},
{
name => 'my_first_new_field',
type => 'set',
options => [
    'yes',
    'no',
    'maybe',
],
input_rows => 1,
},
{
name => 'my_second_new_field',
type => 'set',
options => [
    'yes',
    'no',
    'maybe',
],
input_rows => 1,
},
;


* Define your new fields in <tt>archives/ARCHIVEID/cfg/cfg.d/eprint_fields.pl</tt> for EPrint-level metadata, <tt>.../document_fields.pl</tt> for document-level metadata (this file doesn't exist by default, but is honoured), <tt>.../user_fields.pl</tt> for user metadata, etc etc.


=== EPrints 3.0 ===
Simply make sure your <code>push</code>, is adding your field to the correct dataset you wish to add fields to - in this case an <code>eprint</code> dataset.
 
 
 
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:
 
./bin/epadmin update ARCHIVEID


* Add the new columns to the appropriate tables. There are no longer four separate tables for eprints as there were in EP2 (<tt>archive</tt>, <tt>buffer</tt> etc), so it's simpler.
** For a field defined in <tt>eprint_fields.pl</tt>, the tables are <tt>eprint</tt> and <tt>eprint__ordervalues_en</tt> (replacing <tt>en</tt> with your language as required).
** For a field defined in <tt>document_fields.pl</tt>, you want <tt>document</tt> and <tt>document__ordervalues_en</tt>.
** And so on.
* The column types are the same as for EP2, ie in <tt>eprint</tt> you want a type appropriate to the type of your field exactly as described in the Recipe for EP2 above, while in <tt>eprint__ordervalues_en</tt> you want <tt>text</tt> irrespective of your field type.


=== EPrints 3.1+ ===
=== EPrints 3.1+ ===


Once you have added your new field definitions to the appropriate configuration file you can run the update_database_structure [[API:bin/epadmin|epadmin]] method from the shell:
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
  ./bin/epadmin update_database_structure ARCHIVEID


In EPrints 3.3+ you can use ''update'' as a synonym of ''update_database_structure''.
 
=== 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 (<code>archive</code>, <code>buffer</code> etc), so it's simpler.
** For a field defined in <code>eprint_fields.pl</code>, the tables are <code>eprint</code> and <code>eprint__ordervalues_en</code> (replacing <code>en</code> with your language as required).
** For a field defined in <code>document_fields.pl</code>, you want <code>document</code> and <code>document__ordervalues_en</code>.
** And so on...
* The column types are the same as for EP2, ie in <code>eprint</code> you want a type appropriate to the type of your field exactly as described in the Recipe for EP2, while in <code>eprint__ordervalues_en</code> you want <code>text</code> irrespective of your field type.
 
 
=== EPrints 2.x ===
 
See historical versions of this wiki page.

Revision as of 17:08, 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.pl for EPrint-level metadata,
  • /opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/document_fields.pl for document-level metadata (this file doesn't exist by default, but is honoured),
  • and /opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/user_fields.pl for 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',
	    'maybe',
	],
	input_rows => 1,
},

{
	name => 'my_second_new_field',
	type => 'set',
	options => [
	    'yes',
	    'no',
	    'maybe',
	],
	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:

./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, buffer etc), so it's simpler.
    • For a field defined in eprint_fields.pl, the tables are eprint and eprint__ordervalues_en (replacing en with your language as required).
    • For a field defined in document_fields.pl, you want document and document__ordervalues_en.
    • And so on...
  • The column types are the same as for EP2, ie in eprint you want a type appropriate to the type of your field exactly as described in the Recipe for EP2, while in eprint__ordervalues_en you want text irrespective of your field type.


EPrints 2.x

See historical versions of this wiki page.