cuted (passing it to the searcher) all
> > parameters must be bound.
> > So in terms of optimizations I was thinking that nothing would change.
> >
> > To make sure that we are all in the same page, I created a simple gist
> [1]
> > of how I had in mind to suppo
ge, I created a simple gist [1]
> of how I had in mind to support parameterized queries in Lucene.
> If you think that it is a bad idea then I will go back to the option of
> recreating the query every time.
>
> Best,
> Stamatis
>
> [1] https://gist.github.com/zabetak/ac2a8320c72779
sure that we are all in the same page, I created a simple gist [1]
of how I had in mind to support parameterized queries in Lucene.
If you think that it is a bad idea then I will go back to the option of
recreating the query every time.
Best,
Stamatis
[1] https://gist.github.com/zabetak
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
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
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,
Hi all,
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
