I agree with Atri that it makes little sense to support parameterized
queries like this. Lucene not only uses field statistics but also term
statistics, so we couldn't make decisions about the right way to
execute this query before knowing what the value of `a.name` is.
Supporting something like that would send the message that it makes
things more efficient while in practice it would only save a couple
object creations.
On Wed, Oct 23, 2019 at 9:26 AM Stamatis Zampetakis <zabe...@gmail.com> wrote:
>
> Hi Atri,
>
> Let's assume that we have the following simple SQL query over a Lucene
> index holding book authors.
>
> SELECT *
> FROM authors a
> WHERE a.name = ? AND a.age > 15
>
> The where clause corresponds to a BooleanQuery combining a TermQuery and a
> IntPoint query.
> During the prepare phase of the SQL statement we cannot really construct
> the BooleanQuery since the parameter
> is not yet bound. We have to postpone the creation of the query to the
> execution time of the statement where all parameters are bound. Running the
> same query many times with a different parameter means recreating the Query
> every time.
>
> I admit that creation of the Lucene query is not the most expensive part of
> the planning process still we can gain something by not creating the whole
> query for every single parameter.
>
> In terms of design it appears more natural to build the Lucene query during
> the preparation phase and not during the execution phase.
>
> Best,
> Stamatis
>
>
>
>
> On Mon, Oct 21, 2019 at 2:20 PM Atri Sharma <a...@apache.org> wrote:
>
> > I am curious — what use case are you targeting to solve here?
> >
> > In relational world, this is useful primarily due to the fact that prepared
> > statements eliminate the need for re planning the query, thus saving the
> > cost of iterating over a potentially large combinatorial space. However,
> > for Lucene, there isn’t so much of a concept of a query plan (yet). Some
> > queries try to achieve that (IndexOrDocValuesQuery for eg), but it is a far
> > cry from what relational databases expose.
> >
> > Atri
> >
> > On Mon, 21 Oct 2019 at 17:42, Stamatis Zampetakis <zabe...@gmail.com>
> > wrote:
> >
> > > Hi al
> > > In the world of relational databases and SQL, the existence of
> > > parameterized queries (aka. PreparedStatement) offers many advantages in
> > > terms of security and performance.
> > >
> > > I guess everybody is familiar with the idea that you prepare a statement
> > > and then you execute it multiple times by just changing certain
> > parameters.
> > > A simple use case for demonstrating the idea
> > > is shown below:
> > >
> > > Query q = ... // An arbitrary complex query with a part that has a single
> > > parameter of type int
> > > for (int i=0; i<100; i++) {
> > > int paramValue = i;
> > > q.visit(new ParameterSetter(paramValue));
> > > TopDocs docs = searcher.search(q, 10);
> > > }
> > >
> > > Note that this is a very simplistic use case and does not correspond to
> > the
> > > reality where the construction and execution are not done side by side.
> > >
> > > I already implemented something to satisfy use-cases like the one shown
> > > above by introducing a new subclass of Query. However, I was wondering if
> > > there is already a mechanism to compile and execute queries with
> > parameters
> > > in Lucene and I am just reinventing the wheel.
> > >
> > > Feedback is much appreciated!
> > >
> > > Best,
> > > Stamatis
> > >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> >
--
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
