IIRC, also, a lot of the smaller DB-level defaults (and some of the larger
ones) are the result of various defaults or arbitrary guesses - before just
saying that it's part of the data model and we should just live with it, one
should always positively verify that it's legitimately part of the data model.
In this case, I can actually negatively verify this: in the commit where the
file_version:caption field is added, the DB migration doesn't specify a length
(and so gets the default of 255), but the schema, which is specified, reads:
> "caption" => {"type" => "string", "maxLength" => 16384},
So it's definitely a bug - I'll file a ticket, and I'm planning to make a pull
request to fix this, though it won't really be a solution to your problem until
it gets accepted and you update.
If you have DB access, I think you'd be fine to just go directly in and run:
ALTER TABLE `file_version` MODIFY caption VARCHAR(16384);
Since you're expanding it, you won't risk truncating data.
- Dave Mayo
ASpace Core Committer's Group
On 5/25/18, 9:34 AM, "archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of Brian Harrington"
<archivesspace_users_group-boun...@lyralists.lyrasis.org on behalf of
brian.harring...@lyrasis.org> wrote:
Hi Tim,
I agree it seems a bit backwards to change the data model to suit the
importer, which is one of the reasons I decided to pose the question to the
list. There could be valid reasons (display issues?) for limiting the length
of the caption, but these things are often assigned somewhat arbitrarily, so I
thought I would ask. If there are reasons for keeping for keeping the caption
at 255, then I think it makes sense to truncate it in the importer, rather than
just having things die on a database error.
I currently use a modified version of Mark Custer’s schematron
<https://github.com/fordmadox/schematrons/blob/master/ArchivesSpace-EAD-validator.sch>
to check EADs prior to import, and can certainly add code to check <dao>
@titles. The problem with doing that is the double use of @title for both
digital_object:title and file_version:caption. Since ASpace supports long
titles, and the archivist presumably assigned a long title for a reason, I
would hate to shorten it before import just to make sure that it fits when
re-used as a caption.
Thanks,
Brian
> On May 24, 2018, at 5:25 PM, Timothy Dilauro <ti...@jhu.edu> wrote:
>
> Hi Brian,
>
> I don't think it's a good idea to change the data model just to avoid
imports failing, though there may be other rationales that result in such a
change.
>
> In the mean time, it might be useful to write some XSLT or some other
custom code to perform sanity checks relative to ASpace restrictions ahead of
EAD import attempts. In that manner, those non-conformant captions (and
anything else you check on) could be tweaked before import.
>
> Cheers,
> ~Tim
>
>> On May 23, 2018, at 2:39 PM, Brian Harrington
<brian.harring...@lyrasis.org> wrote:
>>
>>
>> Currently when importing an EAD, <dao>s are used to create digital
objects. As part of this process, the @title attribute is used for both the
digital object title, and the caption under file versions. I've recently run
into a fun issue with <dao>s with @titles longer than 255 characters. These
titles are OK for digital_object:title, which is VARCHAR(8704) but too long for
file_version:caption, which is VARCHAR(255). So the import fails.
>>
>> Should this be considered a bug? If it is, and if one were
theoretically considering a PR, would it make more sense to harmonize the
length of the title and caption, or truncate the caption to 255 characters? My
inclination is just to increase the maximum length of captions, and rely on
people to show restraint, but I know that other people might have different
opinions.
>>
>> Thanks,
>>
>> Brian
>>
>> --
>> Brian Harrington
>> Migration Specialist
>> LYRASIS
>> brian.harring...@lyrasis.org
>> skype: abbistani
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group@lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
