Metadata secondary indexes
Brent Putman
putmanb at georgetown.edu
Mon Oct 5 20:48:31 EDT 2015
On 10/4/15 9:12 AM, Cantor, Scott wrote:
> On 10/2/15, 9:12 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>
>> I basically have the fundamental indexing framework done and tested. Details in the issue. [1] If anyone has any comments/feedback/concerns, let me know.
> Looks nice.
FYI, I'm probably going to change things a bit. Initially I started
with different idea(s), and the way it wound up, I didn't totally like
that the MetadataIndexStore is part of the API, which is so because
MetadataIndex#index(...) calls it. I think it's going to be cleaner to
move all indexing and retrieval into the resovler itself (actually an
auxilliary helper class) and just have MetadataIndex be the mapping
between EntityDescriptor and CriteriaSet -> Set<MetadataIndexKey>.
> One question, is there any value/need to having the IndexKey marker interface include a requirement for implementing Comparable?
>
> Looks like the Store implementation just uses a map that doesn't sort. I don't have a specific use case in mind, I just wondered if that was something to consider.
Hadn't really thought of that. Right now, Sets are used both as return
values of MetadataIndex and how the EntityDescriptors are returned from
the index. The goal being to trivially avoid duplicates. Ordering with
a List didn't seem important. So any ordering of the keys or other
returned data implied by ops via Comparable would be lost. So the way
things are right now, I don't think it would do anything useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20151005/73b7ebde/attachment-0001.html>
More information about the dev
mailing list