Class LuceneSailConnection

java.lang.Object
All Implemented Interfaces:
AutoCloseable, FederatedServiceResolverClient, ThreadSafetyAware, NotifyingSailConnection, SailConnection

public class LuceneSailConnection extends NotifyingSailConnectionWrapper

Sail Connection Listener instead of implementing add/remove

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.
Author:
sauermann, christian.huetter