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.
CND doesn't plan to move on Indexing&&Parsing API in 6.8 timeframe, but we'd like to reuse Lucene index infrastructure. We are responsible for all modifications checks and so on and only need the place where to store our index. Our usages could be like: 1) fill in - get indexer - ask indexer to return IndexDocument for doc_id - put (key, value) into IndexDocument 2) query - ask indexer for IndexResult based on doc_id - query IndexResult for own needs 3) on modification: - invalidate/remove index data for doc_id
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