db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Westerfeld, Kurt" <kwesterf...@managedobjects.com>
Subject RE: [jira] Created: (DERBY-703) VTI Interface "IQualifyable" Semantics Unclear or Broken
Date Fri, 11 Nov 2005 21:46:53 GMT
Actually, I found that in the case of "LIKE 'Smith%'", it pushes two
qualifiers, broken into a > and < operator, or something strange like

I see the commented out "handleQualifier".   I'm not sure what to make
of that.

I'm also thinking I could propose the "easy" fix, which is to make using
IQualifyable simply a notification or interception.  It's a one-liner in

*** 351,357 ****

!               return true;

--- 351,357 ----

!               return false;

This simply keeps the value in both the restrictionList for the
resultset processor as well as recording it in the list to notify to the

I don't know how to proceed--who would be responsible for
accepting/rejecting this?

-----Original Message-----
From: Daniel John Debrunner [mailto:djd@debrunners.com] 
Sent: Friday, November 11, 2005 3:56 PM
To: derby-dev@db.apache.org
Subject: Re: [jira] Created: (DERBY-703) VTI Interface "IQualifyable"
Semantics Unclear or Broken

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:,,,,,,    
>  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
> 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

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.


View raw message