karmi
Remove ActiveModel Dependencies
Karel,
Thank you for writing the Tire gem. We are currently using it here at GitHub to interface with several ElasticSearch indexes, and it has made ES much easier to use for us.
Our main Rails application is still running Rails 2.3, though. In order to use Tire in this context we have created a fork of the project where all the ActiveModel code has been removed. We are contenting to make changes to suit our needs in this fork; however, I do not want this fork to diverge so far from Tire that it essentially becomes a separate project.
Issue #341 describes the very same problem that we encountered. Please let me know how I can help out in the development and improvement of the Tire gem.
I understand that this PR will dramatically change how Tire is used. It is also incomplete in that a second gem needs to be created that encapsulates the ActiveModel code and makes it available to those developers who need it.
Hi, thanks for the kind words, Tim -- I'm happy the library is useful at GitHub!
I believe we already touched this issue previously. I agree that Rails 2.x support is highly desirable.
I'd like to tackle this issue by doing a more invasive decomposition/extraction in the Tire codebase, though. Basically, I'd like to split the gem into several inter-related pieces: HTTP client/adapter, raw API matching elasticsearch's API, Ruby DSL on top of that, ActiveModel model integration on top of that, persistence layer on top of that, etc etc.
This should allow to use the API+DSL layer in any Ruby/Rails codebase, and the ActiveModel integration where possible.
Regarding timeline for this refactoring, I think it should be doable within two or three months. Is that feasible for your use case?
To all interested: I would very much like the feedback on following questions:
- How to make
Itemusable within Rails without ActiveModel? As soon as you do somerequire 'tire/model', you need it. - How to get rid of dependency on ActiveSupport? I hate this dependency as much as any other guy, but the problem is that eg.
Hash#to_paramis very convenient. - Why support integration tests on Ruby 1.8? Need a really convincing argument, there's a slim chance I'd vote for that.
How to make Item usable within Rails without ActiveModel? As soon as you do some require 'tire/model', you need it.
We are not using Item at all with Tire at the moment; so this question is a bit of a moot point. There are actually better solutions to this problem in the form of intridea/hashie and ahoward/map.
All of the tire/model functionality should be in it's own separate gem. This involves splitting out the basic connectivity and request/response framework into a gem, and then build upon that basic framework the more advanced features such as the query DSL and ActiveModel support.
How to get rid of dependency on ActiveSupport? I hate this dependency as much as any other guy, but the problem is that eg. Hash#to_param is very convenient.
The to_param method can be implemented in roughly 20 to 30 lines of code. The same can be said of all the ActiveSupport niceties that Tire might need. So steal what is needed, and leave all the other unneeded things behind.
Why support integration tests on Ruby 1.8? Need a really convincing argument, there's a slim chance I'd vote for that.
Tire is definitely your project, Karel. The production environment we are working with is Ruby 1.8.7 at the moment. The solution we need today has to support 1.8.7. That is the convincing argument for me.
Let's flip this argument on its head. Is there any compelling reason to abandon support for 1.8.7? Is there critical functionality that can only be implemented in Ruby 1.9?
If Tire is going to split into two gems (a base functionality layer and then advanced DSL and ActiveModel features as a separate gem), then keeping the base functionality compatible with 1.8.7 is not a hardship. The advanced features can be 1.9 only.
@TwP Thanks for your input -- though I don't think you understood well what I have been in fact asking.