After a few successful editing and reindexing of any given object, a difficulty has begun to occur, when again saving and in reindexing these Fez Fedora objects. After 3 or 4 editings or reindexing of any objects, their datastream IDs and corresponding file names grow by prepending and embedding the preservation metadata prefix ‘presmd_’ multiple times for successive edits, to such extent that errors result because IDs and names are too long and therefore invalid (written to fez errolog).
We have ingested through the
Is there a way to regulate or configure settings to avoid that problem
of datastream IDs and filenames growing too large? If this cannot be
Also, can versioning be turned off, and if so, then how? While indeed we would prefer to allow versioning for all the Fez Fedora datastreams, until we populate our repository with “permanent”, “stable” records (that is, updated and “finalized” to an extent that numerous updates become minimal), we need to avoid the serious loss in performance and severely increased processing time to reindex even a handful of fez fedora objects, much, much more for a sizable number or even a complete collection, because of all the additional processing of auditing, purging internally stored datastreams, and then recreating the content with growing name lengths and superceding versioning for each serialized object. That, as you know, becomes a major chore just to make even a simple typo correction.
Another major issue that has surfaced is that, as we assign descriptions to file uploads, the datastream labels keep reverting to the original file names, after one or more form edits, even though I have ascertained that the file ‘class.fedora_api.php’, is written to read as posted in:
[Fez-users] saving wrong file description when creating record (2006-08-15 00:19)
I can set the labels in the datastreams manually (from the original filenames to the preferred descriptive text), and they show up properly, until another submit (publish) or reindex is performed. There is no method of editing the attached file descriptions programmatically (unless I have grossly overlooked something), and purging attachments just to be able to restore the preferred descriptions is highly impractical for thousands of records with multiple attached files. That only makes the serialized object grow and grow, as stated above. Have I missed anything from another discussion that resolves this issue of the description labels not getting saved?
I am running
Any input on resolving these would be appreciated.