Erick already pointed you at the "cleanup" rule. This is fairly
generic, but if you know
the properties being modified you should still clean them up in @After or
@AfterClass -- this is useful for other people to know that you're modifying
them, if for nothing else.
Randomized testing package has
Thanks Uwe, I think you are recommending
IndexOrDocValuesQuery/DocValuesRangeQuery, and the articles by Adrien,
https://www.elastic.co/blog/better-query-planning-for-range-queries-in-elasticsearch
It looks promising for my requirement, I will try on that. On Thu, 09 Aug
2018 16:04:27 +080
See TestSolrXml.java for an example of:
@Rule
public TestRule solrTestRules = RuleChain.outerRule(new
SystemPropertiesRestoreRule());
Best,
Erick
On Thu, Aug 9, 2018 at 2:33 PM, Michael Sokolov wrote:
> I ran into a need to test some functionality that relies on system
> properties. Writing the
I ran into a need to test some functionality that relies on system
properties. Writing the test was error-prone because the properties persist
across the jvm so if you set them in a test they leak across to other tests
unless you are careful about @After methods. It occurred to me it would be
nice
Hi,
IMHO: I'd split the whole code into a BooleanQuery with two filter clauses. The
reverse index based condition (term condition, e.g., TermInSetQuery) gets added
as a Occur.FILTER and the DocValues condition is a separate Occur.FILTER. If
Lucene executes such a query, it would use the more sp
Thanks Adrien, I want to filter out docs base on conditions which stored in doc
values (those conditions are unselective ranges which is not appropriate to put
into reverse index), so I plan to use some selective term conditions to do
first round search and then filter in second phase. I see th
