Hi,
I’m talking of the Vals inside the Query Map and not the whole record!
This map should just contain the fields that are also present in the schema, e.g.
<Record>
<Map key="query">
<Val key="author">shakespeare</Val>
<Val key="title">hamlet</Val>
</Map>
</Record>
If this contains a field that is not present in solr then u get of course an error that the field is unknown. So the only use case of the current code, that I can see, would be to prevent such errors. However, the writer of the search would not be made aware that the field he spec’ed doesn’t exist as smila just silently drops it.
BTW: scenario here is, that the user writes an own servlet or uses the generic /SMILA/recordsearch generic and thus be writing the search record himself.
Thomas Menzel @ brox IT-Solutions GmbH
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Stucky
Sent: Mittwoch, 18. Januar 2012 13:19
To: Smila project user mailing list; Smila project developer mailing list
Subject: Re: [smila-dev] Replaced Lucene integration with Solr integration
Hi,
iterating over all available values in the record metadata does not make much sense. The record includes parameters (e.g. maxcount, paging), it possibly includes filters, faceting and in general can contain any kind of data. The intention was to check only for those attributes that are actually searchable within Solr.
BTW, what happens in Solr if attributes are queried that are not part of the schema ?
Bye,
Daniel
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
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