Community
Participate
Working Groups
The implementation of IMetadataRepository currently implements IQueryable. This forces all repository providers to implement the query API which may not be a trivial thing. Instead IMetadataRepository that support query should adapt to IQueryable.
IQueryable is actually trivial to implement for any instance of IMetadataRepository: IQueryable q = new QueryableArray(repository.getInstallableUnits()); Or, if IMetadataRepository only had an iterator method: Iterator it = repository.iterator(); IQueryable q = new CompoundIterator(new Iterator[] {it}, id, range, requirements, and); Another option is to remove the getInstallableUnits() method from IMetadataRepository, and have only IQueryable as the API to retrieve things from the repository. The getInstallableUnits() method is equivalent to: IQueryable.query(null, null, null, false);
yeah, I'm not sure there is much in it either way. The point here really should be that we are free to get efficient impementations of the query mechanism if repos support it. I don't think I really intended to have the repos implement IQueryable when I first did it but was juggling a bunch of different things and it ended up that way. So, I am not fixed on one way or another. There was some concern about the API flexibility impact if the repos etc implement this interface. Then if we add a method to IQueryable the repos have to change.
Also as we looking into this, it may be interesting to look at the repository from JSR 124 and JSR 277.
From a UI point of view, it would be kind of nice to view profiles and repos in terms of the queryable interface. Then my model objects can use queryables to filter views at the profile/repo level. For remote repos (and profiles?) this would speed things up quite a bit. An adapter would be fine with the techniques suggested by John in comment #1 as a fallback.
This bug is no longer an issue. Since clients must subclass AbstractMetadataRepository instead of implementing the interface, we can provide a default IQueryable implementation so repositories don't have to implement it. On the other hand, if we used the adapter approach, then all clients would have to add some default handling for the case where the repository didn't adapt to IQueryable.
