Jasmin Savard

Our current Query Parsers should work with ElasticSearch. Right now the issue is more about the fact that we index differently in Lucene than in Elastic. We don't have an...

Ok, I think I understand why we added the "Stored" option for Lucene. Normally, you should never need to "Store" a ContentField. So, the "Stored" option has been added so...

And here another one about "keyword" data type in ElasticSearch. https://codecurated.com/blog/elasticsearch-text-vs-keyword/ So basically that would be a second option to take into consideration instead of always storing the original value...

Here is what Drupal does : https://www.drupal.org/node/655724 | Drupal | Orchard Core Lucene | ElasticSearch |---------|----------------|------------------------| | UnStored | Analyzed | Analyzed naturally by CLR Type passed | | Keyword...

Elasticsearch allows manual mapping of CLR types : https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/fluent-mapping.html#auto-map-with-overrides

Ok, more on all of this. Right now with ElasticSearch we do not use explicit mapping. But here is a detail I did not know of: Since ElasticSearch 5.0 the...

Just tested this with the ES cloud service with a CloudId and it works.

Also noticed from testing with a database that has around 30k content items that Elasticsearch is really fast at rebuilding the indices. Way faster than Lucene; maybe there is still...

I've been thinking about ways to make the ISearchProviders switchable seemlessly. Right now, the Lucene and Elastic Queries are bound to an Index at all times. We could have a...

Fix conflict by merging latest main branch.