[Biojava-dev] Proposal to change FeatureFilter implementation

[David Huen]

I wish to propose a change to FeatureFilter to better support SQL-based 
SequenceDB implementations.

The proposal is to extend FeatureFilter with an interface SQLFeatureFilter.
interface SQLFeatureFilter extends FeatureFilter
{
    public interface Query
    {
        public Set getColumns();
        public Set getTables();
        public String getWhereClause();
    }

    public Query getQuery(SQLSupport support) 
        throws UnSupportedOperationException;
}

SQLSupport is adaptor code used by the SQLFeatureFilter to generate SQL 
Query objects.

The next thing is to modify the existing FeatureFilters to transparently 
support this interface.

To the current implementation, this proposal would do nothing.

With an SQL-backed implementation, the implementation could pass a 
SQLSupport object to the getQuery method that would be used to generate the 
SQL statement.

For example, in Gadfly, FeatureFilter.ByType("transcript") would return a 
Query object that yielded {"seq_feature"} from getTables() and 
{"seq_feature.type='transcript'"} from getWhereClause().

The FilterFeature logical operator classes would just join the results of 
the getWhereClauses() of child filters and add the tables used by them to 
the Set returned by getTables().

The final SQL statement can then be constructed from the Query object.

Advantages
1) transparent to exisitng code
2) allows existing FeatureFilter optimisers to work on the FeatureFilters 
transparently
3) allows generation of SQL to directly filter on the tables in a manner 
suitable to that particular implementation
4) where appropriate SQL cannot be generated fr that particular 
FeatureFilter combination, the SQL implementation will get the 
UnsupportedOperationException and can revert to the conventional accept() 
method.
5) it could allow quite considerable speedups in SQL implementations

Does anyone have comments? objections? suggestions as to better ways of 
doing it (like adding a getQueryString(SQLSupport support) method that when 
called generates the final string too)?

Regards,
David Huen

-- 

David Huen, Ph.D.              Email: smh1008 at cus.cam.ac.uk
Dept. of Genetics              Fax  : +44 1223 333992
University of Cambridge        Phone: +44 1223 333982/766748
Cambridge, CB2 3UH
U.K.