Rails 2.3 #341

Open
loe opened this Issue May 10, 2012 · 16 comments

10 participants

@loe

I completely understand how tire is targeted at Rails 3 and beyond, thats is the future.

For those of us with some older apps on 2.3 and new things on Rails 3 running shared infrastructure, it would be handy to have Tire function with 2.3.

I have a fork (https://github.com/loe/tire) that works with 99% of the features. I made two important changes, I commented out the need for active_model, and I provided the rack http patch as seen here: loe@53d8510

I'd like to contribute this back to the main project so others can benefit, but I don't like messing with other people's gemspecs. I think ActiveModel should not be required (say like in a Sinatra App) but rather detected and the "additional" model code can be turned on with it.

Thoughts?

@karmi
Owner

Hmm, yeah, I think ActiveModel could be ripped out since that's mostly for Tire::Persistence, I never focused on making Tire Rails 2.3 compatible, but maybe it could be done.

@chendo

+1 on 2.3 support. I was going to use Tire without using the ActiveModel stuff, but the Gemfile requiring activesupport means I have to use @loe's fork. It should be in another gem or something.

@TwP

+1 on this.

Two gems would be highly recommended. The core DSL for interacting with ElasticSearch should be in the tire gem. A second gem needs to be created - tire-model perhaps - that contains all the ActiveModel functionality.

@loe thanks for doing all the hard work on this!

@TwP

@loe you should turn this issue into a pull request.

@karmi
Owner

Yes, splitting the gems in core, model, etc does make sense -- provided we keep the easy setup as is the case now. It should be doable over the coming months.

@kidpollo

@loe @karmi has there been any updates in this issue? I would really like to help out. I am currently testing out @loe changes. I have not gotten to deep into the code so far bui it does seem dunctionality can be broken down. When I built https://github.com/kidpollo/tanker I really wanted to make it orm agnostic. Maybe you want to check out some approaches there.

@karmi
Owner

@kidpollo No updates yet -- the real solution is to extract the Tire::Persistence into separate library, so we don't have to pull ActiveModel directly. I'm not sure how we'll solve the Tire::Results::Item compatibility with Rails without ActiveModel though?

@loe

I have not worked on it, it is up to @karmi to decide how to restructure his project. I think the core/model/etc makes sense.

@vinhboy

+1 for rails 2.3 support

@karmi
Owner

Hi all, I really don't see a good way how to squeeze into Rails with Item being ActiveModel-compatible and all without ActiveModel. Obviously, the DSL should be usable outside of Rails as well.

I'll keep the issue open as a reminder. Until the gem is refactored and split, there's no way I see how to support these features, though.

@ovamsikrishna

Waiting for this......

@tyler-smith

I'm wondering what kind of support there is for doing this. I'm on a Rails 2.3 app and about to implement Elastic. Tire by far seems to the best option, and with a small amount of hackery I have gotten it at least somewhat operational in my stack.

I'm more than happy to look into taking at stab at separating out the active model stuff + perhaps making a 2.3 version if @karmi and others are interested in going this route.

@karmi
Owner

@tyler-smith I don't think putting energy into extracting the model related code is worth it, at the moment.

Besides, I haven't really figured how to make Item behave the way it does currently without ActiveModel, and also, if it makes sense to deal with Rails 2.3 integration when we're nearing Rails 4.0 as current version...

@tyler-smith

Certainly purposefully keeping 2.3 support is probably unnecessary at this point, however it would be nice to have Tire a bit more modular and not require rails at all for many of the more core features. I understand that would require quite a bit of thought/work, and that it may not, and probably is not, quite the direction you're looking to go.

Luckily at this point it seems fairly easy to get a lot of the good stuff by removing the ActiveModel related things, so at least for now maintaining a custom fork is probably a decent option.

@tejo

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment