This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | access to Indexer storage | ||
---|---|---|---|
Product: | editor | Reporter: | Vladimir Voskresensky <vv159170> |
Component: | Parsing & Indexing | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dstrupl, issues |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 190872 | ||
Bug Blocks: |
Description
Vladimir Voskresensky
2009-07-20 15:19:55 UTC
Tomasi, please evaluate. It's coming from the cnd team (see the whiteboard field). There are several possible levels of the support. 1) The lowest - the lucene library is included in the IDE cluster and can be already used, but this does not index reopening, everyone will need to solve the merges, queries himself. This is the case used by java, parsingapi which copies the LuceneIndex class and shares some helpers using implementation dependency. 2) A new low level indexing API should be created (used by parsingapi, java, cnd). This API will be the "low level API". It will provide something like parsingapi's IndexSupport and QuerySupport (without dependency on parsingapi). The implementation part will contain the classes shared in java and parsingapi. The java index is not very generic because of performance. It's question how it will be slowed down by using Document instances rather than Strings. But some kind of convertor can be used to solve this problem. Something like: public class LuceneIndex<T> { public LuceneIndex(final StoreConvertor<? super T> convertor) {...} public add(T data) {....} ..... } public final class IndexingSupport { public static LuceneIndex<Document> createSimpleIndex() {...} public static <T> LuceneIndex<T> createIndex(final StoreConvertor<? super T> convertor){...} } I personally vote against working on this in 6.9. It will require a considerable amount of time; it's potentially harmful for java indexing; it's not a user visible feature and it does not even really improve the current state (except maybe for cnd). Hi Vita, Tomas, We don't need access to LuceneIndex, we need only access to dedicated storage (IndexImpl?) and are responsible for tracking all modifications ourselves. Request is to give us access for the following usage: is = IndexingSupport.getInstance("cnd") doc = is.createDocument(fo); doc.addPair(a, b); is.addDocument(doc); later on to query: q = QuerySupport.for("cnd"); indexResults = q.query(c, d, e, f); All is in place, except the create/access pair: IndexingSupport.getInstance("cnd"); QuerySupport.for("cnd"); Does it simplify things? Thanks, Vladimir. The low level apis were integrated. The low level api allows to store and query user objects. The API is low level as the user needs to provide Convertors from user type to lucene's Document (Query). It's quite easy but the Document based API does not need it. Implemented by Lucene Parsing Support on low level (used by parsing.api and java). I will now create the "parsing api" like level for simpler usage. Fixed jet-main 133f43f39712 Integrated into 'main-golden', will be available in build *201012030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/133f43f39712 User: Tomas Zezula <tzezula@netbeans.org> Log: #168822:access to Indexer storage |