Skip to content

Elasticsearch::Persistence index is overwritten by newly instantiated classes #385

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
JonathanKolnik opened this issue May 6, 2015 · 8 comments
Labels
bug waiting-for-user Waiting for user input to proceed

Comments

@JonathanKolnik
Copy link

split_test_repository.rb

class SplitTestRepository
  include Elasticsearch::Persistence::Repository

  def initialize(test_name, options={})
    index test_name
  end
end

rails console

[15] pry(main)> repo_1 = SplitTestRepository.new('repo_1');
[16] pry(main)> repo_1.index
=> "repo_1"
[17] pry(main)> repo_2 = SplitTestRepository.new('repo_2');
[18] pry(main)> repo_2.index
=> "repo_2"
[19] pry(main)> repo_1.index
=> "repo_2"

Is index a class variable? That seems weird. I don't understand why by instantiating repo_2, repo_1.index now points to repo_2's index

I followed this example https://github.com/elastic/elasticsearch-rails/blob/master/elasticsearch-persistence/README.md#a-custom-class

@karmi
Copy link
Contributor

karmi commented May 8, 2015

@JonathanKolnik Hey, I see you've closed the issue -- how did you solve it? It looks like incorrect instructions or a bug in the library indeed.

@JonathanKolnik
Copy link
Author

@karmi I chickened out and thought I hadn't explored it enough.

repo_1 = SplitTestRepository.new('repo_1')
=> #<SplitTestRepository:0x0000001a042788
 @gateway=
  #<Elasticsearch::Persistence::Repository::Class:0x0000001b11ed40

repo_2 = SplitTestRepository.new('repo_2')
=> #<SplitTestRepository:0x0000001a17af10
 @gateway=
  #<Elasticsearch::Persistence::Repository::Class:0x0000001b11ed40

I think this might be related. Note, @gateway matches. When I use this example https://github.com/elastic/elasticsearch-rails/tree/master/elasticsearch-persistence#the-default-class I don't see the issue.

@JonathanKolnik JonathanKolnik reopened this May 8, 2015
@karmi
Copy link
Contributor

karmi commented May 12, 2015

@JonathanKolnik Yeah, I tried it briefly and I think it's a bug, labelling appropriately...

@karmi karmi added the bug label May 12, 2015
@dimroc
Copy link

dimroc commented Jun 13, 2015

+1

@MMartyn
Copy link

MMartyn commented Sep 23, 2015

@karmi I started to look into this and I am not quite sure how you would want to proceed with this bug. The problem seems to stem from the gateway being made a class method:
https://github.com/elastic/elasticsearch-rails/blob/master/elasticsearch-persistence/lib/elasticsearch/persistence/repository.rb#L46
I started to change it, but then quickly realized that there are tests specifically looking for that behavior.

@estolfo
Copy link
Contributor

estolfo commented Aug 7, 2018

same issue as this one: #811

@estolfo
Copy link
Contributor

estolfo commented Aug 15, 2018

@MMartyn @JonathanKolnik @dimroc
6.0.0.pre versions are available of elasticsearch-rails, elasticsearch-model, and elasticsearch-persistence. They include a refactor so that this problem should be resolved. Feel free to try it out in your testing environment.

@estolfo estolfo added the waiting-for-user Waiting for user input to proceed label Aug 15, 2018
@estolfo
Copy link
Contributor

estolfo commented Sep 6, 2018

I'm closing this as 6.0.0 is released and it includes a fix for this.

@estolfo estolfo closed this as completed Sep 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug waiting-for-user Waiting for user input to proceed
Projects
None yet
Development

No branches or pull requests

5 participants