[
https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020318#comment-14020318
]
Rick Hillegas commented on DERBY-590:
-------------------------------------
Hi Knut,
I think this is a promising approach. I am a little worried about a couple
things:
1) The awkwardness of using one Analyzer to tokenize the document and another
Analyzer to tokenize the query. It's tempting to blame Lucene for mis-factoring
this. Maybe this is unavoidable since Lucene lets you write your own custom
query language. But disturbingly, this may indicate that I don't know what I'm
talking about and have mis-factored Derby.
2) The increasing wordiness of the Derby api. Maybe we need to make the user
declare fields, Analyzer, and QueryParser all at create/update index time.
E.g., introduce an interface like this:
{noformat}
public interface IndexDescriptor
{
public String[] getFields();
public Analyzer getAnalyzer();
public QueryParser getQueryParser;
}
{noformat}
There would be a default IndexDescriptor for the main use case.
Then we could change the signature of createIndex() to…
{noformat}
LUCENESUPPORT.CREATEINDEX
(
SCHEMANAME VARCHAR( 128 ),
TABLENAME VARCHAR( 128 ),
TEXTCOLUMN VARCHAR( 128 ),
INDEXDESCRIPTORMAKER VARCHAR( 32672 ),
KEYCOLUMNS VARCHAR( 32672 ) ...
)
{noformat}
...and simplify the signature of the query table function to...
{noformat}
$SCHEMANAME.$TABLENAME__TEXTCOL
(
QUERY VARCHAR( 32672 ),
WINDOWSIZE INT,
SCORECEILING REAL
)
RETURNS TABLE
(
$keyColumn1 $keyColumn1datatype,
...
$keyColumnN $keyColumnNdatatype,
DOCUMENTID INT,
SCORE REAL
)
{noformat}
If nothing else, this helps future-proof us against other changes to the api
which real users will suggest as they experiment with the plugin. It also means
that the user has to declare only one static method to materialize the index
context.
What do you think?
> 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.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)
