Searchlogic v2 beta was released today, it is a complete rewrite of the library, no code was reused. Right now its in a separate branch under the Searchlogic project, and will be merged when it is taken out of beta status. Let me explain how it’s different.
So, the project I’m working on now required something from Searchlogic v1 that it couldn’t provide. That is, searching with existing named scopes. I could do this, but it wasn’t as elegant as it was with the built in conditions (Ex: username_like, etc.).
So this got me thinking, how can I get Searchlogic v1 to use existing named scopes? That’s when it hit me, why not use named scopes for everything?I think we can all agree named scopes are the heart of searching and breaking up common search logic in your models. Instead of having all of this crazy logic write SQL and chain it together, as in v1, why not have Searchlogic dynamically create these common named scopes for you and then just leverage those? That’s exactly what v2 does. Instead of going into detail about v2, check out the current README. It explains everything v2 has to offer up to this point.
The best part about this approach is that it fits nicely into your application. All that it is doing is creating named scopes. More importantly, if you need some condition that Searchlogic doesn’t offer, no problem, just create your own named scope. This is what you should be doing anyways.
To bring it all home, let me show a simple search form that uses v2. Assume we have
User(name:string, age:integer) Order(user_id:integer, total:float) User.has_manyrders User.named_scope :four_year_olds, :conditions => {:age => 4} User.named_scope :name_sounds_like, lamda { |value| {:conditions => ["name SOUNDS LIKE ?", value]} }
Your search form could look like this:
- form_for @search do |f| = f.text_field :name_like = f.select :age_greater_than, (1..100) = f.text_fieldrders_total_less_than = f.text_field :name_sounds_like = f.check_box :four_year_olds = f.submit
Notice the use of custom named scopes. Also the other conditions are also named scopes that searchlogic dynamically defines as you need them.
As you might have saw in this post Searchlogic v1 was too big for me to handle. The issues people were having would take way too long to solve and I just didn’t like the code. The library really wasn’t advancing and it was just an annoyance. It was regretably the first library I ever wrote, and as such there are a lot of things I would do differently, which should be evident in v2.
That being said, v2 is lean, makes sense, and just feels right. I’m really looking forward to maintaing the library and seeing where it goes. I hope everyone enjoys it. Let me know what you think. There are just a couple of things left to do before I officially release it.
Lastly, because this is such a big change, backwards compatibility will be broken. Before I officially release the library I will write a document explaining the differences and how to transition. In the mean time, your gem declarations in your application should look like this, so that your app doesn’t break when the new version is released:
config.gem "searchlogic", :version => "~> 1.6.6" # the ~ will let you advance minor and tiny versions, but not major versions.
Hello,
Will it be compatible with will_paginate ?
Thank you for your work.
Emilien
Ok, it will paginate, I found my response in the V2 readme
Indeed, this V2 seems really great, can’t wait to test it !
wonderful!
Wow, that looks great.
Thanks a lot for your version1 of the plugin, it can really do amazing things!
I wonder if it is at all possible to implement the OR-conditions and the nestable grouping-functionality with this new approach as well?
(that makes v1 so extremely useful in my eyes)
Greetings
I think I like it. For more complicated queries you can do something like this:
User.named_scope :by_name, lambda {|value| {
:conditions => ["name_a = ? OR name_b = ? OR name_c = ?", value, value, value]
}}
and then the search form:
= f.text_field :by_name
in v1 it’s possible to set up, but way more annoying.
Yep Oleg has it right. One of the things I am going to be more conscientious about with v2 is trying to solve everyone’s problems. That’s one of the things that bloated v2. All of these weird search edge cases. I think “OR” is something that should probably be in the core, I just need to figure out an elegant way to do that. But the great thing about v2 is that you can create a named scope to do anything you want and use it in your search right away. I have A LOT of named scopes in my applications that I want to use in my search forms, now I can.
Awesome! Thank you, Ben, for all the good stuff you provide.
Good Job! Nice plugin!
Now, just a simple question:
I was using v1 succesfully and now I am trying to use v2b (download from git), but I get “undefined method searchlogic_search_proxy_path’” at “”, any idea? Thanks in advance.
Hi Paulo, that’s because your are not explicitly defining a URL in your form_for. There are no helpers in the beta yet, which I plan on adding before I release it. But for the time being you are going to have to explicitly specify a url in your search forms.
[...] Searchlogic v2 beta released – Instant named scopes on the fly via method_missing. [...]
Ben, thank you very much for making Searchlogic working with named_scopes! Searchlogic v1 is still very useful in my app. I will switch to v2 soon.
Ben, thank you – looking forward to messing around with v2.
Thanks for all of the great comments. I have quite a few apps using searchlogic v1 and I have no plans to upgrade them, so I will still be supporting v1 with bug fixes, security fixes, etc. That being said, you don’t have to go change all of your apps to the new version. Unless you need a specific feature don’t waste your time. My current app requires searching by existing named scopes, which is why I am transitioning it.
Hi Ben, do you have any prevision to release v2? thanks
Hi Paulo, I plan on releasing it in a week or 2. I’m trying to integrate it into my own app first to make sure it covers all of the bases.
Way to go, now thats its simpler and i can just juggle with named_scopes i will try to implement it again.
hi Ben. I loved your tutorials for V1. Everything was easy. Unfortunately I am a total dumbass nobrains zombie. e.g. I don’t know how to setup named scope conditions for views/tables like |username|usergroup|number of orders|preferred language|. See what I mean? In V1 I just had to nest a couple of form.fields_for
Please give me and maybe people who are smarter than me (can’t get any dumber) again some nice use cases/tutorials for V2!
p.s. now I’m gonna build in acts_as_list in my V1 code, can’t wait to see it break in V2
p.p.s the little icons for the comments are l33t … i love em!!!
Hey just reading about you comments on how to implement ‘OR’ clause functionality. Maybe having something similar to V1 you can pass in groups eg,
User.search(:name_like => ‘fred’, :group => {:username_equals => ‘ddd’, :city_equals => ‘Auckland’})
Maybe there could be different groups:
:group_all (uses ‘AND’ clause)
:group_any (uses ‘OR’ clause)
:group (use default)
I imagine these groups would make one named_scope for the whole group.
Thoughts?