Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Commit

Permalink
Added notice about 1.0 compatibility to README, added link to elastic…
Browse files Browse the repository at this point in the history 
…search/elasticsearch-rails

Related: #943
  • Loading branch information
@karmi
karmi committed Mar 3, 2014
1 parent 7289d0f commit 0512cc5
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions README.markdown
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,10 @@ Tire

NOTICE: This library has been renamed and retired in September 2013
([read the explanation](https://github.com/karmi/retire/wiki/Tire-Retire)).
It is not considered compatible with Elasticsearch 1.x.

Have a look at the **<http://github.com/elasticsearch/elasticsearch-ruby>**
suite of gems, which will contain similar set of features for
ActiveRecord and Rails integration as Tire.
Have a look at the **<http://github.com/elasticsearch/elasticsearch-rails>** suite of gems,
which contain similar set of features for ActiveModel/Record and Rails integration as Tire.

---------------------------------------------------------------------------------------------------

Expand Down

5 comments on commit 0512cc5

@fredguest
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the plan to have a future release of Tire be compatible with Elasticsearch 1.x or is this gem basically dead now?

@karmi
Copy link
Owner Author

@karmi karmi commented on 0512cc5 Mar 29, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's not much reason to make Tire ES 1.0 compatible, people should simply move to ES 1.0 and the new gems.

"Dead" depends on your definition.

@fredguest
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I understand that you're unhappy with the architectural decisions you made with Tire and are reluctant to enable it's continued use ( http://www.youtube.com/watch?v=U8whfTS3G8U ) but the fact is that Tire has worked very well for a lot of people, largely because of the relatively simple, clean API it provides. The elasticsearch-rails gem is still lacking many of the facilities found in Tire, in addition to the fact there there is no real migration documentation.

I think it would be a lot easier to get people to stop using Tire if there were a clear migration document with lots of implementation code samples, such as the kind found in the Tire readme and not found in the elasticsearch-rails readme, that show how to translate existing Tire code into elasticsearch-rails code, including complex queries, facets, to_indexed_json, and the associated controller/view logic. Without something like that there will be a lot of people that would prefer to continue using Tire. I would write it myself but I have not been programming a long time and I'm certain I would do more harm than good.

@karmi
Copy link
Owner Author

@karmi karmi commented on 0512cc5 Mar 31, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You raise couple of important points in your comments. Let me address them briefly here.

First thing, Tire has indeed many architectural and implementation flaws, apart from its successful features and ideas. The Tire DSL, in particular, is a double-edged sword, and there will be a full-fledged Ruby DSL, as a separate gem, in the near future.

The elasticsearch-rails gem has almost all the features from Tire, and we would need to discuss these point-by-poing, in the elasticsearch-rails issues, not here.

The important point is that Tire is still being maintained, and I'm not opposed to making it compatible with Elasticsearch 1.x where it makes sense. See eg. #947 for evidence.

On the other hand, it doesn't make sense to add features to the gem, or to invest significant amount of time into the maintenance. The world is moving.

Regarding the migration document, that's another idea which cuts both ways. I can see the motivation and benefit from having it, on the other hand, "migration" for simple applications is basically a "find & replace" job. For larger applications, the migration will be very specific.

Instead of a "migration document", see the Rails application templates in the elasticsearch-rails gem, which generate a simple Rails applilcation, with the same spirit as the Tire template, and build much more complex code on top of it.

@fredguest
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO, spinning up a new rails application from a template in order to access the documentation for a gem is not very user friendly. If you care about having as active a community around the elasticsearch-ruby and elasticsearch-rails gems as you have built for the Tire gem (with the help of Ryan Bates), it's important to have the documentation be friendly and easy to access. People are much less likely to spin up an elasticsearch-rails template application than they are to take a quick glance at the Tire readme. I think the implementation code samples in the Tire readme are a perfect example of how to create user friendly docs.

This is great (from the Tire readme):

s = Tire.search 'articles' do
  query do
    string 'title:T*'
  end

  filter :terms, :tags => ['ruby']

  sort { by :title, 'desc' }

  facet 'global-tags', :global => true do
    terms :tags
  end

  facet 'current-tags' do
    terms :tags
  end
end

I can see right away how to create facets for example, and I can see how to display them:

s.results.facets['global-tags']['terms'].each do |f|
  puts "#{f['term'].ljust(10)} #{f['count']}"
end

If I search through all of the elasticsearch-rails docs, i don't even see a single reference to the word "facet". Also, I don't know what to search in the elasticsearch-rails docs to find an equivalent to the to_indexed_json method that Tire makes available, or if one even exists. You say "people should simply move to ES 1.0 and the new gems", but you have not made it simple. I can't even do a "find & replace" because I don't know the terms I need for the "replace" step, because it is not apparent from the elasticsearch-rails docs.

I am not asking or expecting you to reply to these specific questions here, I've just upgraded my local development elasticsearch cluster to ES 1.1.0 and all of my existing Tire code runs perfectly, so I'm quite happy to keep using Tire. I'm just making these points because I assume based on your personal opinion of the Tire gem, that you would be much happier if everyone using Tire would magically stop using it today and switch over to the new gems, so there would be less maintenance to be done and everyone would benefit from the improved architecture - this is not going to happen without better documentation to help people migrate. There's a reason that Tire has 5X the number of stars that elasticsearch-rails has, even though its been called "Retire" for 6 months.

Please sign in to comment.