Using SailConnectionListener, see
above The LuceneIndex is adapted based
on events coming from the wrapped Sail, rather than by overriding the
addStatement and removeStatements methods. This approach has two benefits:
(1) when the wrapped Sail only reports statements that were not stored
before, the LuceneIndex does not have to do the check on the skipped
statemements and (2) the method for removing Statements from the Lucene index
does not have to take wildcards into account, making its implementation
simpler.
Synchronized Methods
LuceneSailConnection uses a listener
to collect removed statements. The listener should not be active during the
removal of contexts, as this is not needed (context removal is implemented
differently). To realize this, all methods that can do changes are
synchronized and during context removal, the listener is disabled. Thus, all
methods of this connection that can change data are synchronized.
Evaluating Queries - possible optimizations
Arjohn has answered this
question in the sesame-dev mailinglist on 13.8.2007:
Is there a
QueryModelNode that can contain a fixed (perhaps very long) list of Query
result bindings? There is currently no such node, but there are two
options to get similar behaviour: 1) Include the result bindings as OR-ed
constraints in the query model. E.g. if you have a result binding like
{{x=1,y=1},{x=2,y=2}}, this translates to the constraints (x=1 and y=1) or
(x=2 and y=2). 2) The LuceneSail could iterate over the LuceneQueryResult and
supply the various results as query input parameters to the underlying Sail.
This is similar to using PreparedStatement's in JDBC.