> even if we could load the elevate.xml file from the data folder in Cloud (or changing it directly in zk), does this make sense in terms of performance? We have frequent commits and a big elevate.xml file.
In terms of performance a big elevate.xml should not be an issue. The structure used for query matching is a tree-like and supports a large number of elevation rules even for subset matching (though it uses more memory). Do you use exact or subset matching? I'm going to fix this elevate-in-data-dir issue in branch 8.9. Le ven. 19 févr. 2021 à 16:39, Mónica Marrero <monica.marr...@europeana.eu> a écrit : > Thank you! I just filed the bug in Jira: > https://issues.apache.org/jira/browse/SOLR-15170 > > About the workaround you mentioned, we ran a quick test on one server and > it apparently worked, but we did not check it properly in a cluster (we > decided that it is better not to go with this in production anyway). Just > out of curiosity, even if we could load the elevate.xml file from the data > folder in Cloud (or changing it directly in zk), does this make sense in > terms of performance? We have frequent commits and a big elevate.xml file. > > We are considering your suggestion of using the elevation directly in the > queries (I have seen work to improve this by removing the requirement of > having an elevate.xml file at all). It seems to be straightforward to apply > in some cases, but not so much when you need normalization. > > -- > Disclaimer: This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity to whom they > are > addressed. If you have received this email in error please notify the > system manager. If you are not the named addressee you should not > disseminate, > distribute or copy this email. Please notify the sender > immediately by email if you have received this email by mistake and delete > this email from your > system. >
