find_inverse_references_by does not work with alternate ids

[awead]

If I create a collection and supply an alternate id:

collection = Collection.new(alternate_id: 'asdf_1234')

And then assign a work to that collection via an inverse relationship:

Work.new(member_of_collection_ids: 'asdf_1234')

I'm unable to get the inverse references:

query_service.find_inverse_references_by(resource: collection, property: 'member_of_collection_ids')

[tpendragon]

@awead You still have to use the ID as the value of the member_of_collection_ids. The alternate ID is just like a slug, a Metadata value to find the collection by.

[awead]

@tpendragon so the method is not intended to work with alternate ids?

[tpendragon]

@awead Yes. That being said, weirdly enough query_service.find_inverse_references_by(id: collection.alternate_id.first, property: :member_of_collection_ids) -would- work, but not for Fedora (until https://github.com/samvera-labs/valkyrie/issues/677 is closed)

Edit: Although I'm not sure I'd recommend it, but I just have strong feelings about the pros of database-generated IDs.

[awead]

@tpendragon Interesting. I think the problem is that we (at Penn State) misinterpreted alternate ids as having the same function as the internal Valkyrie ID, and expected find_inverse_references_by to work with either the internal or alternate id. At least that's how we're currently treating our member_of_collection_ids field: it can be either the generated Valkyrie ID, or the alternate id.

Our problem is that we have a tension between maintaining internal consistency with Valkyrie's own generated ids, and usability with previously-generated local ids.

[tpendragon]

@awead We've considered removing this support, but there's always https://github.com/samvera-labs/valkyrie/blob/master/db/migrate/20161007101725_create_orm_resources.rb#L4 - you could generate the ID yourselves for every resource.

I really wouldn't recommend it though. The previously-generated local IDs seem like slugs to me, and I'd probably treat them that way in your shoes.

[awead]

@tpendragon thanks, I didn't know about that. No, we want to keep Valkyrie's current method of generated ids, and keep our application as closely aligned with it as possible. I think this just arose out of a misunderstanding of alternate ids. Now that we've cleared that up, we going to use only the generated Valkyrie ids as the means of creating relationships between different resources.

There are going to be at least three different kinds of identifiers for us, so I'm looking at defining them each as their own named string properties, but copying them to the alternate_ids array so could search on them.