elasticsearch-persistence not respecting index settings

[MrTin]

What

Under the circumstance that there is no index created yet when you save a model, the client(?) is smart enough to create the index automatically, but it's not respecting the number_of_shards setting provided for the index.

If I create the index first, before saving the model by invoking PageText.gateway.create_index! it will respect the setting and 3 shards will be created.

Example Model

class PageText
  include Elasticsearch::Persistence::Model

  index_name "page_texts-sv"
  settings number_of_shards: 3

  attribute :issue_id, Integer
  attribute :content, String, default: "", mapping: { analyzer: 'swedish' }
end

With index created first

PageText.gateway.create_index!
PageText.create(issue_id: 123, content: "Here's my content.")

# ElasticSearch log output:
# elasticsearch_1  | [2017-03-02T12:18:29,667][INFO ][o.e.c.m.MetaDataCreateIndexService] [fiYQ9r5] [page_texts-sv] creating index, cause [api], templates [], shards [3]/[1], mappings [page_text]

With index automatically created

PageText.gateway.delete_index!
PageText.create(issue_id: 123, content: "Here's my content.")

# ElasticSearch log output:
# elasticsearch_1  | [2017-03-02T12:18:29,667][INFO ][o.e.c.m.MetaDataCreateIndexService] [fiYQ9r5] [page_texts-sv] creating index, cause [api], templates [], shards [5]/[1], mappings [page_text]

[karmi]

I see, thanks for the detailed info! However, this comes from the Elasticsearch layer further "down the stack": in Elasticsearch itself, when an index doesn't exist and a document is being indexed, the index is created with the default settings (and mappings!), which frequently creates a lot of confusion (different analyzers, ...) It can be disabled in Elasticsearch with the action.auto_create_index option.

I'm a bit indecisive about what would be the best thing to do in the elasticsearch-persistence gem. I can see an argument about "just setting things right in ES", but I do see an argument that the model should "guard" the create action, and create an appropriate object.

But there's a larger problem in play: I'm strongly thinking about deprecating and removing the ActiveRecord pattern, in favour of keeping (and improving) the Repository pattern. I haven't made up my mind yet, but it's definitely an option I strongly consider, partially based on my own experience when using elasticsearch-persistence in Ruby applications.

[MrTin]

Sorry for the late reply @karmi and thank you very much for taking the time to reply. I can understand why it's working this way, perhaps it's enough just informing users early on in documentation – a notice.

I feel the same using the AR pattern and will take your consideration and give the Repository pattern a spin.

[hfenton]

@karmi You mentioned deprecating the ActiveRecord pattern

I'm strongly thinking about deprecating and removing the ActiveRecord pattern, in favour of keeping (and improving) the Repository pattern.

Will this pattern be deprecated? If so, do you have a timeline?

I have already implemented my feature in the ActiveRecord pattern and am wondering if I should change patterns now or am I ok to continue.