db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-590) How to integrate Derby with Lucene API?
Date Tue, 10 Jun 2014 11:58:01 GMT

     [ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-590:

    Attachment: multifield-with-custom-tokenizers.diff

Hi Rick,

I basically agree with you.

1) It's a bit awkward, yes. One way to avoid it, might be to allow users to specify a custom
TokenStream class for each field. I tried that approach in the patch [^multifield-with-custom-tokenizers.diff].
With that patch, you specify the fields and the tokenizers in derby.tests.lucene.fields property
like this: field1:nameOfTokenizerClass1,field2:nameOfTokenizerClass2,... If a tokenizer has
been specified for the field, LuceneSupport.createOrRecreateIndex() uses the TextField constructor
that takes a TokenStream instead of the constructor that takes a String. With that approach,
neither a custom analyzer nor a custom query parser is needed in this particular use case.

2) Even without adding support for multiple fields, I think it sounds like an improvement
to allow specifying both analyzer and query parser at index-creation time. Sounds more convenient
than repeating the information about the query parser on each call to the query table function.
I don't have enough experience with Lucene to say if the query parser parameter should be
removed from the table function completely, or if we should keep the ability to override the
query parser for individual queries. My guess is that it's OK to remove the parameter and
only allow one query parser per index.

> How to integrate Derby with Lucene API?
> ---------------------------------------
>                 Key: DERBY-590
>                 URL: https://issues.apache.org/jira/browse/DERBY-590
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation, SQL
>            Reporter: Abhijeet Mahesh
>              Labels: derby_triage10_11
>         Attachments: LucenePlugin.html, LucenePlugin.html, LucenePlugin.html, derby-590-01-ag-publicAccessToLuceneRoutines.diff,
derby-590-01-ah-publicAccessToLuceneRoutines.diff, derby-590-01-am-publicAccessToLuceneRoutines.diff,
derby-590-02-aa-cleanupFindbugsErrors.diff, derby-590-03-aa-removeTestingDiagnostic.diff,
derby-590-04-aa-removeIDFromListIndexes.diff, derby-590-05-aa-accessDeclaredMembers.diff,
derby-590-06-aa-suppressAccessChecks.diff, derby-590-07-aa-accessClassInPackage.sun.misc.diff,
derby-590-08-aa-omitLuceneFlag.diff, derby-590-09-aa-localeSensitiveAnalysis.diff, derby-590-10-aa-fixLocaleTest.diff,
derby-590-11-aa-moveCode.diff, derby-590-12-aa-newJar.diff, derby-590-13-aa-indexViews.diff,
derby-590-14-aa-coarseGrainedAuthorization.diff, derby-590-15-aa-requireHardUpgrade.diff,
derby-590-16-aa-adjustUpgradeTest.diff, derby-590-17-aa-closeInputStreamOnPropertiesFile.diff,
derby-590-18-aa-cleanupAPI.diff, derby-590-19-aa-cleanupAPI2.diff, derby-590-20-aa-customQueryParser.diff,
derby-590-21-aa-noTimeTravel.diff, derby-590-22-aa-cleanupPrivacy.diff, derby-590-23-aa-correctTestLocale.diff,
derby-590-24-ad-luceneDirectory.diff, derby-590-26-ac-backupRestore.diff, derby-590-26-ad-backupRestoreEncryption.diff,
derby-590-27-aa-publicAPILuceneUtils.diff, derby-590-28-renameLuceneJars.diff, derby-590-29-aa-useLucene_4.7.1.diff,
derby-590-30-aa-nullableScoreCeiling.diff, exceptions.diff, lucene_demo.diff, lucene_demo_2.diff,
multifield-with-custom-tokenizers.diff, multifield.diff, netbeans.diff, netbeans2.diff
> In order to use derby with lucene API what should be the steps to be taken? 

This message was sent by Atlassian JIRA

View raw message