Editing Template:EPrints Metadata Fields Content (section)

=== Core Properties ===

{| cellpadding="3" cellspacing="0" border="1"
! Name !! Default Value !! Required !! Description !! Notes
|-
| '''name''' || n/a || YES || This is the internal name of the field. It should only contain alphanumeric characters and underscores. It will be used to identify this field in scripts, other configuration files, in the database, and in the XML export/import system, etc. ||  This property is ''not'' required when defining sub-fields of [[Compound field]]s where <tt>sub_name</tt> should be used. This property affects the database structure.  It must be unique within the [[Data Object]] (so the [[EPrint Object]] cannot have two fields called <tt>email</tt> but the EPrint Object and [[User Object]] can each have a field with the same name.
|-
| '''type''' || n/a || YES || This sets the type of the metafield, which in turn affects what other properties it may have. || This property affects the database structure.  The value must be one of the metafield types listed above.
|-
| '''multiple''' || <tt>0</tt> || NO || This indicates if this field is a single value or a list of values. E.g. <tt>title</tt> is only a single [[Longtext field]] but <tt>creators</tt> is a multiple [[Compound field]]. || This property affects the database structure. In the database a non-multiple field is stored in one (or more) columns in the main object table, but a multiple field gets its own table.
|-
| '''readonly''' || <tt>0</tt> || NO || Whether to not make this field editable in the workflow. || This is useful if you want to display the pre-generated value(s) for this field for reference whilst other fields are being edited.
|-
| '''sql_index''' || <tt>1</tt> || NO || When the database is created this field indicates that an SQL index should be created to speed searching. || This property affects the database structure. Different field types override the default value with the sensible option for that type of field. It is not worth putting a SQL index on a field that is only ever searched for words in it (like title or abstract) but it is worth indexing fields who's values are explicitly searched for, or where ranges are searched (e.g. [[Date field]]s, [[Set field]]s etc.). It is unlikely you will need to set this by hand. You could change it after the database has been created but this will not update the database nor have any other effect.
|- 
| '''sub_name''' || <tt>undef</tt> || YES || This is a special property which is required ''instead'' of the <tt>name</tt> property for the sub-fields inside [[Compound field]]s.  || This property affects the database structure. The actual name of these fields is then forced to be parent field <tt>name + '_' + sub_name</tt>. E.g.  Compound field <tt>creators</tt> is a sub-field with <tt>sub_name => 'name'</tt>. In this case the actual name of the name field in the system, database etc. is <tt>creators_name/tt>.
|-
| '''virtual''' || <tt>0</tt> || NO || Whether this field calculates a value or stores in in the database. || [[Compound field]]s are virtual fields, whereas there sub-fields are not as they store values in the database.  Other types of virtual field will require a <tt>render_value</tt> to be specified, as with no value stored the default render method will have nothing to display.
|-
| '''volatile''' || <tt>0</tt> || NO || Whether the field is liable to change frequently. || Setting <code>volatile => 1</code> will prevent new revisions being create and avoid other post commit events from being triggered, such as re-indexing.
|}