I think I don't understand this architecturally. Maintaining a parallel database of COCINA-derived data seems unfortunate. It still feels like SDR could send us everything we need to know up-front?

And, not just unfortunate, but doesn't this rely on us maintaining an accurate database? Async or parallel operations seem like we could get some inconsistent behavior.

It feels like it'd be nicer if infra maintained the only source of truth and hand over all the data we need in their original request.

It feels like it'd be nicer if infra maintained the only source of truth and hand over all the data we need in their original request.

They do hand over all the data. We just need a way to look at this relationship inversely, just the same as we do with collection membership. This is just a cache of the data.

Maybe I don't understand what we're planning to use this data for. It seems to me, if it's data we need internally to construct the public xml, SDR should provide that to us to avoid any hint of race conditions, non-idempotent behavior, or need for synchronous processing.

@cbeer it will be used to construct the virtual object relationships (e.g. fedora:isConstituentOf in public xml) as seen here: https://github.com/sul-dlss/dor-services-app/blob/main/app/services/published_relationships_filter.rb#L16

At present the infrastructure team is looking this up in the Argo solr (which they are trying to decouple from).
Currently there is no way in the cocina to pass this data, because maintaining bidirectional relationships in flat files is a consistency challenge. In this PR the access team takes on the responsibility for having an index of this data, just as we do for collection membership data. Instead, if we're to require SDR to send this to us, we need to create a new data model that purl-fetcher can use as it's API. This option seems like a bigger project than we can tackle in the dwindling time we have in this maintenance cycle.

In this PR the access team takes on the responsibility for having an index of this data, just as we do for collection membership data

The difference with the collection membership data is that we're not trying to consume that synchronously.

Without infra handing us the data, won't we need to process a virtual object and the constituents in a well-defined order (make sure we've processed all the constituents before the virtual object?) or have some logic to update the virtual object whenever a constituent changes? That seems like at least as much of a pain.

I guess I don't know enough about how the Cocina is managed on the infra side; I guess I assumed there was just a big database they could ask?