db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Created: (DERBY-703) VTI Interface "IQualifyable" Semantics Unclear or Broken
Date Fri, 11 Nov 2005 20:55:38 GMT
Kurt Westerfeld (JIRA) wrote:

> VTI Interface "IQualifyable" Semantics Unclear or Broken
> --------------------------------------------------------
> 
>          Key: DERBY-703
>          URL: http://issues.apache.org/jira/browse/DERBY-703
>      Project: Derby
>         Type: Improvement
>   Components: Store  
>     Versions: 10.1.2.1, 10.1.2.0, 10.1.1.2, 10.1.1.1, 10.1.1.0, 10.0.2.1, 10.0.2.0  
 
>  Environment: This is not a platform-specific issue--more of the programming interface
for internal VTI genration
>     Reporter: Kurt Westerfeld
> 
> 
> Our application wishes to generate some custom VTI implementations.  The VTI package
has an interface called IQualifyable, which when implemented seems like it should pass all
query parameters for the table.  It actually does this, but when implemented by the VTI, effectlively
removes all "WHERE" clause filtering from the SQL engine processing the VTI table request.
 Implementing this interface requires the VTI to handle all such processing.
> 
> As an example, if you had a VTI with table columns "one", "two" and "three", and wanted
to do some special processing for one of the columns by intercepting the IQualifyable interface
(say, column "one"), processing for all three columns would be the responsibility for the
VTI.
> 
> I would propose one of two improvements to resolve this issue:
>    1. Allow the IQualifyable interface to simply have a "crack at it" to see what the
query parameters are, and then allow additional selection processing to occur by the SQL engine,
or 
>    2. Implement a new marker interface or sub-interface of IQualifyable which allows
for the new semantic of intercepting the query parameters provided--similar to IQualifyable
but allowing filtering to occur
> 

That was the original thought, if you see the code you can see a
commented out (partial) method called handleQualifier. This would be
called to dertermine which qualifiers can be pushed down.

I think that currently only qualifiers that can be pushed to the store
are pushed into a vti, thus with this where clause:

   WHERE NAME LIKE 'Smith%' and balance < ?

only the balance < ? would be pushed into the VTI. The LIKE would be
executed with the Derby engine itself.

Dan.


Mime
View raw message