Hi all,
I have checked in a batch of new interfaces in the package
org.tm4j.topicmap.index. These are intended to be an approach to
rationalising the provision of indexing services in TM4J. Basically the
idea is that each topic map has an associated IndexManager which is
responsible for maintaining a collection of IndexProviders. Each
IndexProvider may provide one or more interfaces which must support an
interface derived from the (very simple) Index interface. In the user code,
the intention is that you would do something like this:
IndexManager ixMgr = tm.getIndexManager();
TopicTypeIndex tti =
(TopicTypeIndex)ixMgr.getIndex("org.tm4j.topicmap.index.basic.TopicTypeIndex");
Collection results = tti.getTopicsOfType(myType);
In this case, org.tm4j.topicmap.index.basic.TopicTypeIndex would be an
interface derived from org.tm4j.topicmap.index.Index which adds the
getTopicsOfType() method (and maybe some others). Although the caller knows
which interface she is using, she does not need to know how that interface
is implemented. From an in-memory TopicMap, the implementation returned may
use a Map internally, or it may do a brute-force iteration through all of
the topics in the map. A relational DB might use a query against a
TOPIC_TYPES table. The available indexes will be initialised by the
TopicMapProvider, although the IndexManager interface also allows callers
to extend the set of provided indexes by registering their own indexes at
run-time. We may also want to think about allowing extensions to be
automatically read from a properties file.
Comments ?
Cheers,
Kal
|
