aweber1 / sitecore-elasticsearchprovider Goto Github PK

Same as computed fields.

Originally created at 2013-07-25 22:58:05+00:00 (UTC) by aweber1 as a(n) major issue.

So far, only US English has been used.

Originally created at 2013-07-25 22:59:07+00:00 (UTC) by aweber1 as a(n) major issue.

Sitecore.ContentSearch.ElasticSearchProvider.Linq.ElasticSearchQueryMapper.HandleOr()

When using a 'Missing' filter, the following query works for 99% of items:

#!c#

Query.Filtered(fq => fq.Filter(f => f.Missing(fieldName)));

However, if a field contains a stopword and only a stopword, then it's treated as "missing" by ES.

For example, say you have an item whose "Title" field contains just the word "To" (which is a stopword), if you try to search for all items without a value in the "Title" field (i.e. the field is missing), ES will still return the item whose "Title" field contains just the word "To".

There's possibly a better query to use than a 'Missing' filter... or maybe not, maybe it can only be done with analyzers. Who could say?

Originally created at 2013-07-25 23:19:33+00:00 (UTC) by aweber1 as a(n) minor issue.

Sitecore.ContentSearch.ElasticSearchProvider.Linq.ElasticSearchQueryMapper.HandleOr()

Code in this method currently works quite well, but there is extra code to specifically handle string.IsNullOrEmpty in this method. The Lucene provider doesn't have this extra code but the Solr provider does. Why?

Originally created at 2013-07-25 23:15:35+00:00 (UTC) by aweber1 as a(n) minor issue.

Sitecore.ContentSearch.ElasticSearchProvider.LinqToElasticSearchIndex.Execute()

Elasticsearch allows you to assign arbitrary 'types' for the documents you index. Think of these types as (more or less) categories as opposed to types you find in programming languages (i.e. string, int, etc...).

When executing a search against an ES index, you can specify which types to search against. Currently, the provider code just does a blanket search against all types in the index. Ideally, the provider would be able to infer the type(s) to search against based on a mapping or attribute or generic argument, etc.. The indexing functions would need to infer types as well so that documents are stored with the proper type declaration.

There's probably a pretty straightforward way to do this (notice I didn't say "easy"), but not tonight.

Originally created at 2013-07-25 23:38:58+00:00 (UTC) by aweber1 as a(n) major issue.

Sitecore.ContentSearch.ElasticSearchProvider.Linq.ElasticSearchQueryMapper.HandleNot()

Code in this method currently works for basic term (field) queries, but both the Linq and Solr providers have code that does "more". Need to test with more queries.

Originally created at 2013-07-25 23:12:24+00:00 (UTC) by aweber1 as a(n) minor issue.

Field mapping is only partially implemented at the moment. While you could technically specify a

#!xml

<fieldMap />

definition at the moment, it probably wouldn't do what you'd expect. Or, more likely, it would result in many beautiful YSOD.

The default FieldReaders work at the moment though, so there's at least some intelligent field processing going on.

Originally created at 2013-07-25 22:55:22+00:00 (UTC) by aweber1 as a(n) major issue.

Sitecore.ContentSearch.ElasticSearchProvider.Linq.ElasticSearchQueryMapper.HandleContains(), HandleStartsWith(), HandleEndsWith()

According to ES docs, wildcard queries do not scale well with large indexes. Googling around for alternate solutions alludes to using n-gram analyzers and regular term queries.

The question is, how to implement such analyzing and querying so that it works "out of the box" as opposed to having to tweak field maps/storage settings?

Probably an easy way to accomplish this, but I'm experiencing search overload. (search is complicated!)

Originally created at 2013-07-25 23:24:21+00:00 (UTC) by aweber1 as a(n) major issue.

Sitecore.ContentSearch.ElasticSearchProvider.LinqToElasticSearchIndex.Execute

When processing Count and Any methods, the current code uses the Nest.SearchDescriptor.Size method to set the result set size. Lucene and Solr both parse/process these methods differently and unfortunately their code doesn't directly translate into something usable via NEST.

Originally created at 2013-07-25 23:50:14+00:00 (UTC) by aweber1 as a(n) major issue.

It is unknown at the moment whether computed fields will work with the provider. Maybe?

Originally created at 2013-07-25 22:57:28+00:00 (UTC) by aweber1 as a(n) major issue.

Facet queries and all facet-related goodness has not been implemented yet.

Sitecore.ContentSearch.ElasticSearchProvider.Linq.ElasticSearchQueryMapper.HandleMatchNone()

The current code seems to be working, but it's so simple it doesn't seem right...

Originally created at 2013-07-25 23:26:01+00:00 (UTC) by aweber1 as a(n) major issue.

Is it possible to serialize a NEST query without instantiating Nest.ElasticClient to use its Serialize method?

Would like the ability to serialize a Nest query in the Sitecore.ContentSearch.ElasticSearchProvider.Linq.ElasticSearchQuery.Dump() method.

Originally created at 2013-07-25 23:09:04+00:00 (UTC) by aweber1 as a(n) minor issue.

Currently, only the bare minimum of logging is occurring. Need to be more liberal with logging usage.

Originally created at 2013-07-25 23:51:17+00:00 (UTC) by aweber1 as a(n) trivial issue.

See TODO comments in Sitecore.ContentSearch.ElasticSearchProvider.ElasticSearchResults.

Basically, when processing results, we have to retrieve field values for an individual Hit (document) from the Hit.Source property as opposed to the Hit.Fields property. I have to assume this is related to incomplete field mapping.

The code in place currently works, but it's probably not ideal.

Originally created at 2013-07-25 23:05:11+00:00 (UTC) by aweber1 as a(n) minor issue.