VeggieMeat / search_api_elasticsearch

Clone of project at drupal.org/project/search_api_elasticsearch for better CI options than what D.O offers
16 stars 8 forks source link

Entity translation support #79

Open tappleby opened 9 years ago

tappleby commented 9 years ago

Based on our discussion on twitter, it would be nice to have support for entity translation (et).

The Solr and DB backends have support via the search_api_et module. I was able to get data indexed using the et. module by modifying the id schema type. My issue with the mentioned module is a document is created per language and put into the same index:

image

The Solr et module uses dynamic fields with the document language added to translatable fields (this solves invalid inverse document frequency issues).

When using the search_api_page module results are filtered using the search_api_language condition.

An index per language feels like the most flexible approach although I can see some use cases for field per language.

tappleby commented 9 years ago

@VeggieMeat you mentioned using aliases instead of having to maintain multiple views. I am curious how this would look for mapping to the correct index based on the current users language (or perhaps across multiple). Is this logic handled on the drupal or ES side (not too familiar with ES aliases)?

VeggieMeat commented 9 years ago

The primary reason for aliases (see #76) is to avoid the downtime issues caused by Search API's reindex process as well as the rebuilds required when changing index configuration or mappings in Elasticsearch.

My thinking is that, on a multilingual site, language specific aliases would be maintained, such as my_sapiindex. The format for aliases in #76 is for an alias of my_sapi_index to point to my_sapiindex. The idea is for configuration or mapping updates or for re-indexing to create a new index, copy data as necessary, and then re-point the alias when the process is complete.

Another benefit is that aliases can point to multiple indices, or they can even point to filtered indices. In this case, my thinking was a global alias would be provided that would point across all language indices and be used by default. We could provide an option in the Search API Views configuration to use the global alias or the language-specific alias.

tappleby commented 9 years ago

I think the aliases will be useful. As far as the Search API Views configuration, the ideal use case for my current setup would be to dynamically set the alias/index based on the views "Item Language" filter criteria.

Its still a bit unclear to me how multiple elasticsearch index's per language would be maintained. Would these be managed as separate drupal SearchApiIndex? Or could a single drupal index map to multiple elasticsearch indexes behind the scenes?

VeggieMeat commented 9 years ago

A single Drupal index can map to multiple Elasticsearch indexes.