searchlogic 2.3.1 → 2.3.2
Sign up to get free protection for your applications and to get access to all the features.
- data/CHANGELOG.rdoc +5 -0
- data/README.rdoc +22 -1
- data/VERSION.yml +1 -1
- data/lib/searchlogic/named_scopes/alias_scope.rb +1 -0
- data/lib/searchlogic/named_scopes/conditions.rb +1 -1
- data/searchlogic.gemspec +2 -2
- data/spec/named_scopes/conditions_spec.rb +2 -2
- metadata +2 -2
data/CHANGELOG.rdoc
CHANGED
data/README.rdoc
CHANGED
@@ -8,6 +8,7 @@ Searchlogic makes using ActiveRecord named scopes easier and less repetitive. It
|
|
8
8
|
* <b>Repository:</b> http://github.com/binarylogic/searchlogic/tree/master
|
9
9
|
* <b>Issues:</b> http://github.com/binarylogic/searchlogic/issues
|
10
10
|
* <b>Google group:</b> http://groups.google.com/group/searchlogic
|
11
|
+
* <b>Railscast:</b> http://railscasts.com/episodes/176-searchlogic
|
11
12
|
|
12
13
|
<b>Before contacting me directly, please read:</b>
|
13
14
|
|
@@ -83,6 +84,8 @@ Typing out 'greater_than_or_equal_to' is not fun. Instead Searchlogic provides v
|
|
83
84
|
|
84
85
|
This is my favorite part of Searchlogic. You can dynamically call scopes on associated classes and Searchlogic will take care of creating the necessary joins for you. This is REALY nice for keeping your code DRY. The best way to explain this is to show you:
|
85
86
|
|
87
|
+
=== Searchlogic provided scopes
|
88
|
+
|
86
89
|
Let's take some basic scopes that Searchlogic provides for every model:
|
87
90
|
|
88
91
|
# We have the following relationships
|
@@ -100,14 +103,18 @@ Let's take some basic scopes that Searchlogic provides for every model:
|
|
100
103
|
|
101
104
|
This is recursive, you can travel through your associations simply by typing it in the name of the method. Again these are just named scopes. You can chain them together, call methods off of them, etc.
|
102
105
|
|
106
|
+
=== Custom associated scopes
|
107
|
+
|
103
108
|
Also, these conditions aren't limited to the scopes Searchlogic provides. You can use your own scopes. Like this:
|
104
109
|
|
105
110
|
LineItem.named_scope :expensive, :conditions => "line_items.price > 500"
|
106
111
|
|
107
|
-
User.orders_line_items_expensive
|
112
|
+
User.orders_line_items_expensive
|
108
113
|
|
109
114
|
As I stated above, Searchlogic will take care of creating the necessary joins for you. This is REALLY nice when trying to keep your code DRY, because if you wanted to use a scope like this in your User model you would have to copy over the conditions. Now you have 2 named scopes that are essentially doing the same thing. Why do that when you can dynamically access that scope using this feature?
|
110
115
|
|
116
|
+
=== Uses :joins not :include
|
117
|
+
|
111
118
|
Another thing to note is that the joins created by Searchlogic do NOT use the :include option, making them <em>much</em> faster. Instead they leverage the :joins option, which is great for performance. To prove my point here is a quick benchmark from an application I am working on:
|
112
119
|
|
113
120
|
Benchmark.bm do |x|
|
@@ -163,6 +170,18 @@ You can do:
|
|
163
170
|
|
164
171
|
Again, these just map to named scopes. Use Searchlogic's dynamic scopes, use scopes on associations, use your own custom scopes. As long as it maps to a named scope it will join the conditions with 'OR'. There are no limitations.
|
165
172
|
|
173
|
+
== Create scope procedures
|
174
|
+
|
175
|
+
Sometimes you notice a pattern in your application where you are constantly combining certain named scopes. You want to keep the flexibility of being able to mix and match small named scopes, while at the same time being able to call a single scope for a common task. User searchlogic's scpe procedure:
|
176
|
+
|
177
|
+
User.scope_procedure :awesome, lambda { first_name_begins_with("ben").last_name_begins_with("johnson").website_equals("binarylogic.com") }
|
178
|
+
|
179
|
+
All that this is doing is creating a class level method, but what is nice about this method is that is more inline with your other named scopes. It also tells searchlogic that this method is 'safe' to use when using the search method. Ex:
|
180
|
+
|
181
|
+
User.search(:awesome => true)
|
182
|
+
|
183
|
+
Otherwise searchlogic will ignore the 'awesome' condition because there is no way to tell that its a valid scope. This is a security measure to keep users from passing in a scope with a named like 'destroy_all'.
|
184
|
+
|
166
185
|
== Make searching and ordering data in your application trivial
|
167
186
|
|
168
187
|
The above is great, but what about tying all of this in with a search form in your application? What would be really nice is if we could use an object that represented a single search. Like this...
|
@@ -267,6 +286,8 @@ Before I use a library in my application I like to glance at the source and try
|
|
267
286
|
|
268
287
|
Searchlogic utilizes method_missing to create all of these named scopes. When it hits method_missing it creates a named scope to ensure it will never hit method missing for that named scope again. Sort of a caching mechanism. It works in the same fashion as ActiveRecord's "find_by_*" methods. This way only the named scopes you need are created and nothing more.
|
269
288
|
|
289
|
+
The search object is just a proxy to your model that only delegates calls that map to named scopes and nothing more. This is obviously done for security reasons. It also helps make form integration easier, by type casting values, and playing nice with form_for. This class is pretty simple as well.
|
290
|
+
|
270
291
|
That's about it, the named scope options are pretty bare bones and created just like you would manually.
|
271
292
|
|
272
293
|
== Credit
|
data/VERSION.yml
CHANGED
@@ -122,7 +122,7 @@ module Searchlogic
|
|
122
122
|
when "blank"
|
123
123
|
{:conditions => "#{table_name}.#{column} = '' OR #{table_name}.#{column} IS NULL"}
|
124
124
|
when "not_blank"
|
125
|
-
{:conditions => "#{table_name}.#{column} != ''
|
125
|
+
{:conditions => "#{table_name}.#{column} != '' AND #{table_name}.#{column} IS NOT NULL"}
|
126
126
|
end
|
127
127
|
|
128
128
|
named_scope("#{column}_#{condition}".to_sym, scope_options)
|
data/searchlogic.gemspec
CHANGED
@@ -5,11 +5,11 @@
|
|
5
5
|
|
6
6
|
Gem::Specification.new do |s|
|
7
7
|
s.name = %q{searchlogic}
|
8
|
-
s.version = "2.3.
|
8
|
+
s.version = "2.3.2"
|
9
9
|
|
10
10
|
s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
|
11
11
|
s.authors = ["Ben Johnson of Binary Logic"]
|
12
|
-
s.date = %q{2009-08-
|
12
|
+
s.date = %q{2009-08-26}
|
13
13
|
s.description = %q{Searchlogic makes using ActiveRecord named scopes easier and less repetitive.}
|
14
14
|
s.email = %q{bjohnson@binarylogic.com}
|
15
15
|
s.extra_rdoc_files = [
|
@@ -96,12 +96,12 @@ describe "Conditions" do
|
|
96
96
|
|
97
97
|
it "should have blank" do
|
98
98
|
["bjohnson", "", nil].each { |username| User.create(:username => username) }
|
99
|
-
User.username_blank.all.should == User.
|
99
|
+
User.username_blank.all.should == [User.find_by_username(""), User.find_by_username(nil)]
|
100
100
|
end
|
101
101
|
|
102
102
|
it "should have not blank" do
|
103
103
|
["bjohnson", "", nil].each { |username| User.create(:username => username) }
|
104
|
-
User.username_not_blank.all.should == User.
|
104
|
+
User.username_not_blank.all.should == User.find_all_by_username("bjohnson")
|
105
105
|
end
|
106
106
|
end
|
107
107
|
|
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: searchlogic
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 2.3.
|
4
|
+
version: 2.3.2
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Ben Johnson of Binary Logic
|
@@ -9,7 +9,7 @@ autorequire:
|
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
11
|
|
12
|
-
date: 2009-08-
|
12
|
+
date: 2009-08-26 00:00:00 -04:00
|
13
13
|
default_executable:
|
14
14
|
dependencies:
|
15
15
|
- !ruby/object:Gem::Dependency
|