Community
Participate
Working Groups
The current API to list all the ius returns an InstallableUnit[]. This forces all the IUs to be loaded in memory which may not be suitable / scalable when running with very little memory, or when the content of many repositories needs to be loaded. Instead, the API should return an Iteration. Of course there may be concurrency issues when the repo is modified while it is being iterated though this advantage of this approach outweigh the drawbacks and repositories are usually pretty static.
indeed and repos may be implemented such that they actually support concurrent modification.
I think that getting the IU's from a Profile and from a metadata repo should work the same way. I keep bumping into the inconsistency where the repo returns an array and the Profile returns the iterator. I was going to use the queryable interface instead to keep it uniform, but given bug #192466, I'm not sure if that's so safe either.
This has been addressed through new IQueryable API, which can return an Iterator.
Reopening this one. There is still the getInstallableUnits() API in IMetadataRepository, which returns an array, and getInstallableUnits() in Profile, which returns an Iterator. I understand that the queryable interface for each class can be used to get an array or iterator, but if we are keeping a convenience method in these classes, shouldn't they behave the same?
Ugh. I have removed IMetadataRepository.getInstallableUnits(), fixing up all references to use queries, mostly with a visitor that avoids creating garbage arrays of all IUs in the repository. I'm now onto Profile.getInstallableUnits(), but there are a lot of references to it, so it may take awhile.
Done.
