Hi folks,
i was wondering a little about the new code in the SearchPipelet regarding fielded search, the code looks thus:
/**
* build the query string. Takes it either from smila's query string and which must be a native string then OR if that
* is empty constructs one from smila's fielded search syntax.
*/
private void doQuery(final List<String> schemaAttributes) {
String q = _accessor.getQuery();
if (StringUtils.isEmpty(q)) {
// search in dedicated fields instead of simple query string
if (schemaAttributes != null && !schemaAttributes.isEmpty()) {
final StringBuilder fieldQuery = new StringBuilder();
for (final String field : schemaAttributes) {
final List<Value> fieldQueryValues = _accessor.getQueryAttributeValues(field);
if (fieldQueryValues != null) {
// there seems to be no SolrQuery API for querying fields so we have to build our query manually
SolrQueryUtils.appendFieldQueryPart(fieldQuery, field, fieldQueryValues);
}
}
q = fieldQuery.toString().trim();
}
// Filters are added in doFilterSettings()
}
if (!StringUtils.isEmpty(q)) {
_solrQuery.setQuery(q);
}
}
The code up to now allowed for a mapping of the record attributes/attachments to solr fields (not supporting a dynamic mapping of record fields to solr fields, but that could be introduced of needed).
However, the method is passed a set of attributes that are in the schema and only these will end up being added to the query.
What is the reason for this?
I see really no good need for this limitation and would just iterate over all Val items in the query Map and append them to the solr query…
Thomas Menzel @ brox IT-Solutions GmbH
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Jürgen Schumacher
Sent: Montag, 16. Januar 2012 15:11
To: Smila project developer mailing list
Cc: Smila project user mailing list
Subject: Re: [smila-dev] Replaced Lucene integration with Solr integration
Hi,
I’ve removed the org.apache.solr.allinone bundle and moved the required Lucene and Solr bundles to SMILA.extension, so you will need to reload your target platform. We had some problem afterwards with the bundles org.apache.lucene + .core + .analysis, because the same bundles are part of the Eclipse 3.7 SDK which we usually use as the base of the target platform. It seems that the PDE does not like such duplicates and then neither of the duplicates is included correctly in the target platform, and it wasn’t easy or even predictable in which order one had to change which setting to get this working. So I removed those three bundles from SMILA.extension.
This means, that from now on by default SMILA will require an Eclipse 3.7 SDK as the base of the target platform. I hope this doesn’t cause any problems for anyone and not more inconvenience than having to update the workspace settings (-;
Cheers,
Juergen.
Hi everyone,
I just checked in a major change with the replacement of the Lucene integration with Solr. All Lucene related bundles where removed from the repository. You have to update your workspaces accordingly and you have also to migrate any custom Search/Indexing-Pipelines as well as index schemas to Solr.
Please note that the replacement is not completely finished, yet. There are a couple of issues that will be addressed within the next weeks:
- Currently only the “Default” search works, “Advanced” search is not supported yet
- Field search, filters and sortBy are not supported yet
- Bundle org.apache.solr.allinone will probably be replaced with separate Solr/Lucene bundles from Orbit
- Wiki documentation is not up to date
Please report any issues or problems so that we can address them prior to the 1.0 release.
Bye,
Daniel