Hi Sujit,
Many thanks for your blog post, responding to my question, and suggesting the
alternative option ☺
I think I prefer your approach because we can supply our own Comparator. The
reason is that we need to meet some strict requirements: we can only call the
external system once to r
Hi all,
I am implementing a PostFilter following this article
https://lucidworks.com/blog/custom-security-filtering-in-solr/
We have a requirement to call the external system only once for all the
documents (max 200) so below is my change:
-don't call super.collect(docId) in the collect method
Thanks Ahmet. There are couple reasons we couldn't index those fields:
1. pricing logic is complex and must be done in ERP.
2. price requires real-time update if indexed
3. those fields could be changed frequently, for example inventory, while we
try to minimize index update because we have a huge
This ticket seems to address the problem I have
https://issues.apache.org/jira/browse/SOLR-1566
and as the result of that ticket, DocTransformer is added since Solr 4.0. I
wrote a simple DocTransformer and found that the transformer is executed AFTER
pagination. In our application, we need th
We are also evaluating an option in which each document has 600K fields
(scalable tested with 1M fields). Index/reindex/query performance is
acceptable (~2.5h to index 130K docs using 1 machine, query time <20ms),
however atomic update took lots of memory and time. Hope can help.
-Ha Pham
---
