Fredrik Adelöw
Fredrik Adelöw
Oh wow, that's obscure! Thanks for digging into it. Would you like to contribute that change in a pull request? Should be safe since they are functionally equivalent.
@mmonroe-vmware Would you have the ability to check if latest master still exhibits this problem on safari, after this change? https://github.com/backstage/backstage/pull/12397
I don't know of one offhand.
@martina-if Would you like to chip in on this discussion?
There's effectively an OR between entries in the filter array. So while a bit awkward, you can filter by `[{ kind:... }, { kind:... }]` and split the result array...
> @vinzscam that will load all of the records into memory which is undesirable. Not really, his example was basically like mine but only used `name` instead of specifying the...
I see both your points above, but I think a key realization is that this is fully possible to build from the client point of view already without any backend...
I bet there's a breaking point where the batch fetch is faster than individual items. It'll surely depend on the available concurrency etc too
@taras Oh you really shouldn't have the `entity_to_ref` there. You should start from `processing_state` which does have the ref already, and join that with `final_entities`.
Yeah sorry - wrong table name! Essentially no migration should be necessary at all; the model is already set up to support what you need.