index_name should accept a lambda in additional to a string

[l4u]

No description provided.

[oliviermilla]

+1

[redox]

Yes it's more complex than just a lambda evaluation, the underlying "cache" that avoids to call the {get,set}_settings endpoint need to be redesigned to add that feature.

[seantanly]

Without the lambda support, how do we get the one-index-per-language to work?

https://www.algolia.com/doc/guides/search/multilingual-search#option-1-one-index-per-language

[redox]

Without the lambda support, how do we get the one-index-per-language to work?

https://www.algolia.com/doc/guides/search/multilingual-search#option-1-one-index-per-language

In such case (because from what I understand each object has its own language) I would recommend a 3rd option: what about pushing all the objects to a single index and tag them with the associated language:

{
  objectID: 42,
  myattr: "my value",
  [...],
  _tags: ["language_en"]
}

At search time, you could filter the search with a tagFilters to only retrieve the results that matter for your language:

index.search("my query in english", { tagFilters: "language_en" })

How does that sound?

[seantanly]

In such case (because from what I understand each object has its own language)...

Sorry, I wasn't specific in my original question. I'm using https://github.com/bithavoc/multilang-hstore and each object contains multiple languages for locale-aware attributes.

I would need to search on these locale-aware attributes, i.e. title, description.

So I guess a possible solution is to send all the locale aware attributes in flattened format and create slave indexes on them, and during search choose the right language index?

E.g.

algoliasearch index_name: "Book_en_#{Rails.env}" do
  attribute ['title_en', 'title_fr', 'description_en', 'description_fr']

  attributesToIndex ["ordered(title_en)", "unordered(description_en)"]  

  add_slave "Book_fr_#{Rails.env}" do
    attributesToIndex ["ordered(title_fr)", "unordered(description_fr)"]
  end
end

[phildionne]

I have a similar use case, where every organization has n documents. An organization should only be searching in an index where it's own documents are present.

@redox in your opinion, is enabling to pass a lambda requires lots of work? If yes, is it significantly less performant to use the tagFilters approach?

[redox]

I have a similar use case, where every organization has n documents. An organization should only be searching in an index where it's own documents are present.

Actually @phildionne, for that you should rather go for 1 index and use the Secured API Key like described in #138 (comment)

@redox in your opinion, is enabling to pass a lambda requires lots of work? If yes, is it significantly less performant to use the tagFilters approach?

The only issue I have adding the lambda is that the gem is also trying to keep the underlying index settings in sync with the one defined with the DSL in the algoliasearch block. Having a way to pass a lambda there breaks the strategy of "applying" the settings at class-load time.

[phildionne]

Awesome! Thanks for pointing this out, works very well :)

[jmirmina]

We are running into a similar situation where we need to dynamically define an index name (or at least an index prefix). We are currently using the Apartment gem to handle multiple schemas.

For example, if we have a Blog model, the index will be named 'blog', but we need to prefix it with the current tenant/schema name, so 'schema_1_blog', 'schema_2_blog', etc.

I was able to monkey patch the algolia_index_name method to prefix the index name with Apartment::Tenant.current, but based on the above comment, there is some underwater caching that might not work correctly.

Any thoughts on a better way to handle this? Or are we pushing this gem to it's limits with our implementation? Thanks!

[redox]

Any thoughts on a better way to handle this? Or are we pushing this gem to it's limits with our implementation? Thanks!

Thanks for sharing that use-case with us. I personally didn't know about the Apartment gem -> definitely something we should take into account for the v2 of this gem.

Unfortunately, the current gem architecture is really not suitable for the multi-index approach; what I would therefore recommend is to use the underlying Ruby API client and handle the addition/update/removal of objects yourself using the regular model callbacks. You should also setup the index settings from the db:seed and any rake command you could call at deployment time.

Let us know how that goes!