Also: Is flatmap stable?

That's a good question. :D

I know I need to do some refactoring that method is huge. I'm going to do it in a bit.

@jakobmoellerdev So now I added hashing to the sorting, but that's not what you mean here, right:

Im currently missing a hash method for the configs to accomodate our phase 2

But this exists, what other kind of hashing did you have in mind?

Im referring to the hash that can be used to uniquely key config content so that we can use it in the resolution service to determine if we need to initialize a new repository

Im referring to the hash that can be used to uniquely key config content so that we can use it in the resolution service to determine if we need to initialize a new repository

I'm sorry, I might be stupid, but I don't understand how what you are saying here is different from what exists right now that I'm already using to produce a hash for the config data. :D Could you please elaborate the difference?

I believe that we should epxose the hash you are already generating here: https://github.com/open-component-model/open-component-model/pull/1014/files#diff-a6095938c6975e7550d720d60b23d93bdd2cbbe3155b9d72b79431a4de1037d8R72

This will be needed because otherwise consumers like the resolution service will have to compute it again from scratch. To be exact, I dont really understand why you use the hash to sort. In the end the input needs to be sorted and the output needs to be a hash. You are currently hashing all objects, and then sorting the objects by hash. That is not really the same though for me (maybe Im stupid as well :D )

For the reference on the above comment. We talked about this on Slack, and now I understand what Jakob is saying. :D

Basically, since the original Hasher hashes all objects and all their Data segment including any random key they might provide, this is insufficient.

However, now, given the flatmap that is basically a stable representation of the config compacted. This is now easy to hash. We can just marshal it, and run it through sha256 and done. That's what we are doing now. The configuration order is based on the reference declaration in the original object spec.

We also parallelize the Get calls to make it a bit more performant since this is a very critical code section.