Community
Participate
Working Groups
We use 'member providers' in p2ql as a way of making objects 'inspectable'. If an object is not a member provider, then the p2ql engine must use refelection each time the object is accessed. Since ResolvedIUs are not 'member providers' these IUs take a long time to process.
Created attachment 180897 [details] Patch v1 Here is a patch that adds 'member provider' support to the Resolved IU.
In which circumstances are we being hit by this? CC'ing Thomas has we likely want him to review the patch.
We are being hit by this if we query ResolvedIUs. After we plan, we end up with resolved IUs in our collections, and these queries end up being slower.
Thomas, could you please take a look at Ian patch? It applies still fine and it seems good, but I would rather have your opinion on it, especially that late in the cycle. Thx.
The patch looks good but I have two questions: 1. Why is 'original' and 'fragments' are exposed as members? They are not part of the API. Do we have special queries that need access to them? 2. Why are all the original members redeclared and not reused? They are public in InstallableUnit class that resides in the same package, so why the redundancy?
I've cleaned up the patch to avoid the duplication of the constants. I have left the declaration of original and fragments for now since I assume this could be used to write queries in very specific circumstances (e.g. processing a list of know resolved IUs). I'll let Ian decide if we should keep it or not. I have released the version of this adapted patch.
Why is this bug still open?
Yes, I put those there so you could write specific queries. It's all internal, so I don't think there is any harm. Pascal, did you actually commit to this to RC1 (you committed on the 9th)? You have a +1 on the patch and Tomas H. looked at this too, so I think we are good.
I kept that opened because I had comments for Ian to address and he was away when I released this.
