Prevent downstream use of `alternate_id` field

[hackartisan]

How should we resolve the conflict between hyrax needing to use this field to store the noid and Valkyrie offering it as a reserved field for general use? Should hyrax allow more general use, or reserve it more tightly? Should hyrax advocate for discriminating between different types of alternate_ids?

If we want to reserve it more tightly, hyrax should error upon discovering downstream use and provide instructions for migrating the field values to another field.

[no-reply]

notably, Hyrax only needs to use this to store the noid if Hyrax.config.enable_noids? is true.

when that flag is false i think alternate_id shouldn't be reserved.

[tpendragon]

I can't come up with a proposed success criteria for this one. I don't understand what "downstream use means" - we should talk about this ticket at standup. Valkyrie explicitly made this field to support FCRepo's noid use cases.

[hackartisan]

notably, Hyrax only needs to use this to store the noid if Hyrax.config.enable_noids? is true.

when that flag is false i think alternate_id shouldn't be reserved.

@no-reply good point. If that config defaults to false maybe it's enough to put a comment in the generated configuration file.

The scenario I imagined is that someone has a hyrax app that uses noids, starts storing other values in alternate_id without realizing, and overwrites the noid values and loses them. If that's not a technical concern then let's close this.

[tpendragon]

We can depend on downstream applications having test suites that would catch this before they went to production. We think if this was going to be a problem in production applications, it would have happened years ago when we started using Wings.

We recommend closing it.