Attachments
Each feature type can define one or more references to attachment. Attachment can be referenced to no more than one feature type. Possibility of having an attachment is inherited from parent feature type to child.
Attributes
-
id – Unique identifier of an attachment.
-
name – Name of an attachment.
-
storage – This attribute specifies storage type of an attachment. It can be either 'database' or 'filesystem'.
-
secured – Specifies whether or not the access rights are applied for an attachment.
-
georeferenced – Identifies whether or not the attachment contains geographical location.
-
userLink – Value comes from list: 'required'; 'optional'; 'prohibited'.
Inner Elements
-
description – Contains a detailed description of the attachment.
-
featureType – With attribute refId to set a related feature type for the attachment type. Optional.
Example: Attachment type definition.
<ber:attachmentTypeArray>
<ber:attachmentType id="att_pumpingstation_e" name="Pumping station - exterior" storage="database" secured="false">
<ber:description>Picture of pumping station exterior</ber:description>
</ber:attachmentType>
<ber:attachmentType id="att_pumpingstation_i" name="Pumping station - interior" storage="database" secured="true">
<ber:description>Picture of pumping station interior</ber:description>
</ber:attachmentType>
<ber:attachmentType id="att_pumpingstation_f" name="Pumping station - file system geo" storage="filesystem" secured="false" georeferenced="true" userLink="prohibited">
<ber:description>Georeferenced picture of pumping station stored on application server file system</ber:description>
</ber:attachmentType>
<ber:attachmentType id="att_pumpingstation_l" name="Pumping station - link" storage="database" secured="false" georeferenced="false" userLink="required">
<ber:description>Link attachment type</ber:description>
</ber:attachmentType>
<ber:attachmentType id="att_general_d" name="General attachment - DB, geo" storage="database" secured="false" georeferenced="true">
<ber:description>Stored in the database, georeferenced</ber:description>
<ber:featureType refId="ft_g_attachment"/>
</ber:attachmentType>
<ber:attachmentType id="att_general_f_att" name="General attachment - FS + att" storage="filesystem" georeferenced="true">
<ber:description>Georeferenced picture with attributes stored on application server file system</ber:description>
<ber:featureType refId="ft_g_attachment"/>
</ber:attachmentType>
</ber:attachmentTypeArray>
Versioning attachments
The attachments can maintain historical versions. New versions are generated automatically when updating an attachment, with the possibility to enter the description of every version.
Whether an attachment type is versioned or not depends on the master feature type definition. So, if a feature type is defined as versioned, its attachments are versioned as well.
Versioning is possible only for attachment type with storage="database". Versioning is not possible for attachment type with storage="filesystem".
Historical versions of attachments are stored in LIDS_DOCUMENT_H table. The names / labels of the versions are stored in LIDS_DOC_VERSION table. In current functionality the cardinality between these tables is 1:1. But theoretically there can be more records in the LIDS_DOCUMENT_H table related to one labelled version in LIDS_DOC_VERSION.
When versioned master feature is deleted, the related versioned attachments (with storage="database") remain preserved in LIDS_DOCUMENT table. If the deleted master feature is restored, the attachments are automatically available.