[
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
(v6.2#6252)
