[
https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13948464#comment-13948464
]
Mike Matrigali commented on DERBY-590:
--------------------------------------
I continue to think that derby.jar is the wrong place for this tool and
other optional tools. I do not feel strongly it need go into derbytools.jar,
just that it should go in some other jar. Functionally I am looking to ways
to insure new optional tools do not add to code bloat (both disk and runtime)
to base server users who do not want the optional tools. Looking to insure
this by having separate jars and by being able to run full sets of non-optional
tools tests with a classpath that does not include these optional tool jars.
>
> Or maybe I misunderstand you. Are you suggesting that we crack open the Lucene
jars and put all their contents together with the plugin into a single Lucene-s
pecific jar? I think there will be problems with that approach.
No, I am not suggesting this - we should leave lucene jars alone. I assume
this project does not need any lucene jar changes, just uses existing
interfaces. I am hoping similarly the lucene optional tool need not have
derby changes, just use existing generic optional tool interfaces (which may
need to be altered as we learn new interfaces to provide for all new tools).
>
> Are you suggesting that we allocate a separate jar file to each optional tool?
I did suggest this as a point for discussion. I don't have strong
opinions one way or another as long as the libraries and dependencies are
separate from the base server. Some optional tools may make more sense
to group together, like the various existing diagnostic tools. To me lucerne
seems very different.
>
> Yes, please, I would like more discussion about the transactional behavior of
the Lucene plugin. Having another set of eyes on this would be very helpful. In
particular, I want to reduce the chance that users will experience deadlocks bet
ween Lucene's locks and Derby's locks.
I have to admit at this point I have not looked very closely at this other
than to note that the implementation seems not finished, and seemed to allow
for the index to not be up to date with the data (but would get there
eventually). I am fine with incremental development in the trunk.
The index not being in sync with the data is not going to be SQL standard so
was hoping it would not be part of the main product.
I do see that lucene searching in a non-SQL
compatible way may be quite useful to some users, so did not want to get
in the way - but still see it as something different than the derby project.
> 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: 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, lucene_demo.diff,
> lucene_demo_2.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)
