[Biojava-l] Is there a way to determine the query within a FeatureFilter?

[Matthew Pocock]

In additon to what Thomas said, you may also want to look at the 
org.biojava.utils.walker package and its use in the FilterUtils code 
(arround line 986). This is a framework we developed to make it trivial 
to walk a fiter expression, possibly building an sql query as you go.

Matthew

Thomas Down wrote:

>Once upon a time, Benjamin Schuster-Boeckler wrote:
>  
>
>>Benjamin Schuster-Boeckler wrote:
>>
>>    
>>
>>>As I understood the principle, a FeatureFilter will be used to test 
>>>one Feature after the other through it's accept(Feature f) method. Now 
>>>my problem is that this is _far_ too slow. I need to check millions of 
>>>Features of which only a few will be selected. So what I want to do is 
>>>to get the "rule" that the FeatureFilter uses and translate it into a 
>>>SQL query so I can get the right Features from the database straight 
>>>away. Unfortunately, I don't see a way how this could be possible. 
>>>      
>>>
>>Ah, toString() could do it, am I right? I think it returns a neat 
>>pattern that I could parse token for token...
>>    
>>
>
>You certainly could do this if you wanted to.  However, I would
>generally advise against it.  If you look at all the FeatureFilter
>implementations in BioJava, you'll find that they all have accessor
>methods for getting at their parameters.  So while it's possible
>to convert a filter to text then parse it again, you'd do better
>by looking at filters as parse-trees, ready to analyse directly.
>
>You'll find code which manipulates FeatureFilters in this way
>throughout the BioJava code base.  One bit which might be
>particularly relevant to you is the (private) method sqlizeFilter
>in BioSQLSequenceDB.  It's pretty simplistic, but might give you
>some ideas.
>
>One thing to remember is that you don't have to translate
>every part of a complex filter to SQL -- just do the easy/
>important bits, then use the FeatureFilter.accept methods
>to apply the parts of the filter your translater doesn't
>understand, and you should still get correct results with
>good performance.
>
>In the past, David Huen has talked about some more general
>solutions for FeatureFilter -> SQL translation, so he might
>want to add something here,
>
>     Thomas.
>_______________________________________________
>Biojava-l mailing list  -  Biojava-l at biojava.org
>http://biojava.org/mailman/listinfo/biojava-l
>
>  
>