kazjote-searchlogic 2.1.9.3 → 2.3.4

data/CHANGELOG.rdoc

@@ -1,4 +1,61 @@
-== 2.1.8
+== 2.3.3 released 2009-09-02
+
+* Split out merging scopes with 'or' into a convenient method.
+
+== 2.3.2 released 2009-08-26
+
+* Add in scope_procedure as an alias for alias_scope.
+* Fixed bug with not_blank condition.
+
+== 2.3.1 released 2009-08-24
+
+* Added blank and not_blank conditions.
+* Made User.whatever_like_any("val1", "val2") consistent with User.whatever_like_any(["val1", "val2"])
+
+== 2.3.0 released 2009-08-22
+
+* Thanks to laserlemon for support of ranges and arrays in the equals condition.
+* Added feature to combine condition with 'or'.
+
+== 2.2.3 released 2009-07-31
+
+* Fixed bug when an associations named scope joins is a string or an array of strings, the joins we add in automatically should also be a string, not a symbol.
+
+== 2.2.2 released 2009-07-31
+
+* Fix bug to give priority to local columns.
+
+== 2.2.1 released 2009-07-30
+
+* Use ::ActiveRecord instead of ActiveRecord to avoid a name conflict since ActiveRecord is a module within Searchlogic.
+
+== 2.2.0 released 2009-07-30
+
+* Refactored association code to be much simpler and rely on recursion. This allows the underlying class to do most of the work. This also allows calling any named scopes through any level of associations.
+
+== 2.1.13 released 2009-07-29
+
+* Applied bug fix from http://github.com/skanev/searchlogic to make #order work with association ordering.
+* Applied bug fix to allow for custom ordering conditions.
+
+== 2.1.12 released 2009-07-28
+
+* Fixed bug when dealing with scopes that return nil.
+
+== 2.1.11 released 2009-07-28
+
+* Reworked how alias conditions are created on the fly, uses scope(:find) instead of proxy_options to create the scope. This allows using association alias named scopes.
+
+== 2.1.10 released 2009-07-28
+
+* Ignore polymorphic associations when dynamically creating conditions on associations.
+
+== 2.1.9 released 2009-07-28
+
+* Fixed bug when cloning with no scope
+* Allow the call of foreign pre-existing named scopes instead of those generated by searchlogic. Allows you to call named scopes on associations that you define yourself.
+
+== 2.1.8 released 2009-07-15
 
 * Added support for not_like, not_begin_with, not_end_with, and not_null
 

data/README.rdoc

@@ -1,19 +1,18 @@
 = Searchlogic
 
-<b>Searchlogic has been <em>completely</em> rewritten for v2. It is much simpler and has taken an entirely new approach. To give you an idea, v1 had ~2300 lines of code, v2 has ~420 lines of code.</b>
-
-Searchlogic provides common named scopes and object based searching for ActiveRecord.
+Searchlogic makes using ActiveRecord named scopes easier and less repetitive. It helps keep your code DRY, clean, and simple.
 
 == Helpful links
 
 * <b>Documentation:</b> http://rdoc.info/projects/binarylogic/searchlogic
 * <b>Repository:</b> http://github.com/binarylogic/searchlogic/tree/master
-* <b>Bugs / feature suggestions:</b> http://binarylogic.lighthouseapp.com/projects/16601-searchlogic
+* <b>Issues:</b> http://github.com/binarylogic/searchlogic/issues
 * <b>Google group:</b> http://groups.google.com/group/searchlogic
+* <b>Railscast:</b> http://railscasts.com/episodes/176-searchlogic
 
 <b>Before contacting me directly, please read:</b>
 
-If you find a bug or a problem please post it on lighthouse. If you need help with something, please use google groups. I check both regularly and get emails when anything happens, so that is the best place to get help. This also benefits other people in the future with the same questions / problems. Thank you.
+If you find a bug or a problem please post it in the issues section. If you need help with something, please use google groups. I check both regularly and get emails when anything happens, so that is the best place to get help. This also benefits other people in the future with the same questions / problems. Thank you.
 
 == Install & use
 
@@ -42,35 +41,52 @@ Instead of explaining what Searchlogic can do, let me show you. Let's start at t
   
   # Searchlogic gives you a bunch of named scopes for free:
   User.username_equals("bjohnson")
+  User.username_equals(["bjohnson", "thunt"])
+  User.username_equals("a".."b")
   User.username_does_not_equal("bjohnson")
   User.username_begins_with("bjohnson")
+  User.username_not_begin_with("bjohnson")
   User.username_like("bjohnson")
+  User.username_not_like("bjohnson")
   User.username_ends_with("bjohnson")
+  User.username_not_end_with("bjohnson")
   User.age_greater_than(20)
   User.age_greater_than_or_equal_to(20)
   User.age_less_than(20)
   User.age_less_than_or_equal_to(20)
   User.username_null
+  User.username_not_null
   User.username_blank
-  
-  # You can also order by columns
-  User.ascend_by_username
-  User.descend_by_username
-  User.order("ascend_by_username")
 
 Any named scope Searchlogic creates is dynamic and created via method_missing. Meaning it will only create what you need. Also, keep in mind, these are just named scopes, you can chain them, call methods off of them, etc:
 
-  scope = User.username_like("bjohnson").age_greater_than(20).ascend_by_username
+  scope = User.username_like("bjohnson").age_greater_than(20).id_less_than(55)
   scope.all
   scope.first
   scope.count
   # etc...
 
-That's all pretty standard, but here's where Searchlogic starts to get interesting...
+For a complete list of conditions please see the constants in Searchlogic::NamedScopes::Conditions.
+
+== Use condition aliases
+
+Typing out 'greater_than_or_equal_to' is not fun. Instead Searchlogic provides various aliases for the conditions. For a complete list please see Searchlogic::NamedScopes::Conditions. But they are pretty straightforward:
+
+  User.username_is(10)  # equals
+  User.username_eq(10)  # equals
+  User.id_lt(10)        # less than
+  User.id_lte(10)       # less than or equal to
+  User.id_gt(10)        # greater than
+  User.id_gte(10)       # greater than or equal to
+  # etc...
+
+== Search using scopes in associated classes
 
-== Search using conditions on associated columns
+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:
 
-You also get named scopes for any of your associations:
+=== Searchlogic provided scopes
+
+Let's take some basic scopes that Searchlogic provides for every model:
 
   # We have the following relationships
   User.has_many :orders
@@ -85,7 +101,21 @@ You also get named scopes for any of your associations:
   User.ascend_by_order_total
   User.descend_by_orders_line_items_price
 
-Again these are just named scopes. You can chain them together, call methods off of them, etc. What's great about these named scopes is that they do NOT use the :include option, making them <em>much</em> faster. Instead they create a INNER JOIN and pass it to the :joins option, which is great for performance. To prove my point here is a quick benchmark from an application I am working on:
+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.
+
+=== Custom associated scopes
+
+Also, these conditions aren't limited to the scopes Searchlogic provides. You can use your own scopes. Like this:
+
+  LineItem.named_scope :expensive, :conditions => "line_items.price > 500"
+  
+  User.orders_line_items_expensive
+
+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?
+
+=== Uses :joins not :include
+
+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:
 
   Benchmark.bm do |x|
     x.report { 10.times { Event.tickets_id_gt(10).all(:include => :tickets) } }
@@ -99,7 +129,58 @@ If you want to use the :include option, just specify it:
 
   User.orders_line_items_price_greater_than(20).all(:include => {:orders => :line_items})
 
-Obviously, only do this if you want to actually use the included objects.
+Obviously, only do this if you want to actually use the included objects. Including objects into a query can be helpful with performance, especially when solving an N+1 query problem.
+
+== Order your search
+
+Just like the various conditions, Searchlogic gives you some very basic scopes for ordering your data:
+
+  User.ascend_by_id
+  User.descend_by_id
+  User.ascend_by_orders_line_items_price
+  # etc...
+
+== Use any or all
+
+Every condition you've seen in this readme also has 2 related conditions that you can use. Example:
+
+  User.username_like_any("bjohnson", "thunt")   # will return any users that have either of the strings in their username
+  User.username_like_all("bjohnson", "thunt")   # will return any users that have all of the strings in their username
+  User.username_like_any(["bjohnson", "thunt"]) # also accepts an array
+
+This is great for checkbox filters, etc. Where you can pass an array right from your form to this condition.
+
+== Combine scopes with 'OR'
+
+In the same fashion that Searchlogic provides a tool for accessing scopes in associated classes, it also provides a tool for combining scopes with 'OR'. As we all know, when scopes are combined they are joined with 'AND', but sometimes you need to combine scopes with 'OR'. Searchlogic solves this problem:
+
+  User.username_or_first_name_like("ben")
+  => "username LIKE '%ben%' OR first_name like'%ben%'"
+  
+  User.id_or_age_lt_or_username_or_first_name_begins_with(10)
+  => "id < 10 OR age < 10 OR username LIKE 'ben%' OR first_name like'ben%'"
+
+Notice you don't have to specify the explicit condition (like, gt, lt, begins with, etc.). You just need to eventually specify it. If you specify a column it will just use the next condition specified. So instead of:
+
+  User.username_like_or_first_name_like("ben")
+
+You can do:
+
+  User.username_or_first_name_like("ben")
+
+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.
+
+== Create scope procedures
+
+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:
+
+  User.scope_procedure :awesome, lambda { first_name_begins_with("ben").last_name_begins_with("johnson").website_equals("binarylogic.com") }
+
+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:
+
+  User.search(:awesome => true)
+
+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'.
 
 == Make searching and ordering data in your application trivial
 
@@ -178,17 +259,7 @@ Now just throw it in your form:
     = f.check_box :four_year_olds
     = f.submit
 
-What's great about this is that you can do just about anything you want. If Searchlogic doesn't provide a named scope for that crazy edge case that you need, just create your own named scope. The sky is the limit.
-
-== Use any or all
-
-Every condition you've seen in this readme also has 2 related conditions that you can use. Example:
-
-  User.username_like_any("bjohnson", "thunt")   # will return any users that have either of the strings in their username
-  User.username_like_all("bjohnson", "thunt")   # will return any users that have all of the strings in their username
-  User.username_like_any(["bjohnson", "thunt"]) # also accepts an array
-
-This is great for checkbox filters, etc. Where you can pass an array right from your form to this condition.
+This really allows Searchlogic to extend beyond what it provides internally. If Searchlogic doesn't provide a named scope for that crazy edge case that you need, just create your own named scope and use it. The sky is the limit.
 
 == Pagination (leverage will_paginate)
 
@@ -201,7 +272,7 @@ If you don't like will_paginate, use another solution, or roll your own. Paginat
 
 == Conflicts with other gems
 
-You will notice searchlogic wants to create a method called "search". So do other libraries like thinking sphinx, etc. So searchlogic has a no conflict resolution. If the "search" method is already taken the method will be called "searchlogic" instead. So instead of
+You will notice searchlogic wants to create a method called "search". So do other libraries like thinking-sphinx, etc. So searchlogic has a no conflict resolution. If the "search" method is already taken the method will be called "searchlogic" instead. So instead of
 
   User.search
 
@@ -215,6 +286,8 @@ Before I use a library in my application I like to glance at the source and try
 
 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.
 
+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.
+
 That's about it, the named scope options are pretty bare bones and created just like you would manually.
 
 == Credit

data/Rakefile

@@ -5,14 +5,15 @@ begin
   require 'jeweler'
   Jeweler::Tasks.new do |gem|
     gem.name = "searchlogic"
-    gem.summary = "Searchlogic provides common named scopes and object based searching for ActiveRecord."
-    gem.description = "Searchlogic provides common named scopes and object based searching for ActiveRecord."
+    gem.summary = "Searchlogic makes using ActiveRecord named scopes easier and less repetitive."
+    gem.description = "Searchlogic makes using ActiveRecord named scopes easier and less repetitive."
     gem.email = "bjohnson@binarylogic.com"
     gem.homepage = "http://github.com/binarylogic/searchlogic"
     gem.authors = ["Ben Johnson of Binary Logic"]
     gem.rubyforge_project = "searchlogic"
     gem.add_dependency "activerecord", ">= 2.0.0"
   end
+  Jeweler::RubyforgeTasks.new
 rescue LoadError
   puts "Jeweler (or a dependency) not available. Install it with: sudo gem install jeweler"
 end
@@ -29,15 +30,6 @@ Spec::Rake::SpecTask.new(:rcov) do |spec|
   spec.rcov = true
 end
 
+task :spec => :check_dependencies
 
 task :default => :spec
-
-begin
-  require 'rake/contrib/sshpublisher'
-  namespace :rubyforge do
-    desc "Release gem to RubyForge"
-    task :release => ["rubyforge:release:gem"]
-  end
-rescue LoadError
-  puts "Rake SshDirPublisher is unavailable or your rubyforge environment is not configured."
-end

data/VERSION.yml

@@ -1,4 +1,4 @@
 --- 
+:patch: 3
 :major: 2
-:minor: 1
-:patch: 8
+:minor: 3

data/lib/searchlogic/active_record/consistency.rb

@@ -0,0 +1,22 @@
+module Searchlogic
+  module ActiveRecord
+    # Active Record is pretty inconsistent with how their SQL is constructed. This
+    # method attempts to close the gap between the various inconsistencies.
+    module Consistency
+      def self.included(klass)
+        klass.class_eval do
+          alias_method_chain :merge_joins, :searchlogic
+        end
+      end
+      
+      # In AR multiple joins are sometimes in a single join query, and other times they
+      # are not. The merge_joins method in AR should account for this, but it doesn't.
+      # This fixes that problem. This way there is one join per string, which allows
+      # the merge_joins method to delete duplicates.
+      def merge_joins_with_searchlogic(*args)
+        joins = merge_joins_without_searchlogic(*args)
+        joins.collect { |j| j.is_a?(String) ? j.split("  ") : j }.flatten.uniq
+      end
+    end
+  end
+end

data/lib/searchlogic/active_record/named_scopes.rb

@@ -0,0 +1,60 @@
+module Searchlogic
+  module ActiveRecord
+    # Adds methods that give extra information about a classes named scopes.
+    module NamedScopes
+      # Retrieves the options passed when creating the respective named scope. Ex:
+      #
+      #   named_scope :whatever, :conditions => {:column => value}
+      #
+      # This method will return:
+      #
+      #   :conditions => {:column => value}
+      #
+      # ActiveRecord hides this internally in a Proc, so we have to try and pull it out with this
+      # method.
+      def named_scope_options(name)
+        key = scopes.key?(name.to_sym) ? name.to_sym : primary_condition_name(name)
+        
+        if key
+          eval("options", scopes[key].binding)
+        else
+          nil
+        end
+      end
+      
+      # The arity for a named scope's proc is important, because we use the arity
+      # to determine if the condition should be ignored when calling the search method.
+      # If the condition is false and the arity is 0, then we skip it all together. Ex:
+      #
+      #   User.named_scope :age_is_4, :conditions => {:age => 4}
+      #   User.search(:age_is_4 => false) == User.all
+      #   User.search(:age_is_4 => true) == User.all(:conditions => {:age => 4})
+      #
+      # We also use it when trying to "copy" the underlying named scope for association
+      # conditions. This way our aliased scope accepts the same number of parameters for
+      # the underlying scope.
+      def named_scope_arity(name)
+        options = named_scope_options(name)
+        options.respond_to?(:arity) ? options.arity : nil
+      end
+      
+      # A convenience method for creating inner join sql to that your inner joins
+      # are consistent with how Active Record creates them. Basically a tool for
+      # you to use when writing your own named scopes. This way you know for sure
+      # that duplicate joins will be removed when chaining scopes together that
+      # use the same join.
+      #
+      # Also, don't worry about breaking up the joins or retriving multiple joins.
+      # ActiveRecord will remove dupilicate joins and Searchlogic assists ActiveRecord in
+      # breaking up your joins so that they are unique.
+      def inner_joins(association_name)
+        ::ActiveRecord::Associations::ClassMethods::InnerJoinDependency.new(self, association_name, nil).join_associations.collect { |assoc| assoc.association_join }
+      end
+      
+      # See inner_joins, except this creates LEFT OUTER joins.
+      def left_outer_joins(association_name)
+        ::ActiveRecord::Associations::ClassMethods::JoinDependency.new(self, association_name, nil).join_associations.collect { |assoc| assoc.association_join }
+      end
+    end
+  end
+end

data/lib/searchlogic/core_ext/object.rb

@@ -27,8 +27,10 @@ module Searchlogic
       #
       #   named_scope :id_gt, searchlogic_lambda(:integer) { |value| {:conditions => ["id > ?", value]} }
       #
-      # If you are wanting a string, you don't have to do anything, because Searchlogic assumes you are want a string.
-      # If you want something else, you need to specify it as I did in the above example.
+      # If you are wanting a string, you don't have to do anything, because Searchlogic assumes you want a string.
+      # If you want something else, you need to specify it as I did in the above example. Comments are appreciated
+      # on this, if you know of a better solution please let me know. But this is the best I could come up with,
+      # without being intrusive and altering default behavior.
       def searchlogic_lambda(type = :string, &block)
         proc = lambda(&block)
         proc.searchlogic_arg_type = type

data/lib/searchlogic/named_scopes/alias_scope.rb

@@ -1,20 +1,11 @@
 module Searchlogic
   module NamedScopes
     # Adds the ability to create alias scopes that allow you to alias a named
-    # scope or create a named scope procedure, while at the same time letting
-    # Searchlogic know that this is a safe method.
+    # scope or create a named scope procedure. See the alias_scope method for a more
+    # detailed explanation.
     module AliasScope
-      # The searchlogic Search class takes a hash and chains the values together as named scopes.
-      # For security reasons the only hash keys that are allowed must be mapped to named scopes.
-      # You can not pass the name of a class method and expect that to be called. In some instances
-      # you might create a class method that essentially aliases a named scope or represents a
-      # named scope procedure. Ex:
-      #
-      #   User.named_scope :teenager, :conditions => ["age >= ? AND age <= ?", 13, 19]
-      #
-      # This is obviously a very basic example, but there is logic that is duplicated here. For
-      # more complicated named scopes this might make more sense, but to make my point you could
-      # do something like this instead
+      # In some instances you might create a class method that essentially aliases a named scope
+      # or represents a named scope procedure. Ex:
       #
       #   class User
       #     def teenager
@@ -22,13 +13,24 @@ module Searchlogic
       #     end
       #   end
       #
-      # As I stated above, you could not use this method with the Searchlogic::Search class because
-      # there is no way to tell that this is actually a named scope. Instead, Searchlogic lets you
-      # do something like this:
+      # This is obviously a very basic example, but notice how we are utilizing already existing named
+      # scopes so that we do not have to repeat ourself. This method makes a lot more sense when you are
+      # dealing with complicated named scope.
+      #
+      # There is a problem though. What if you want to use this in your controller's via the 'search' method:
+      #
+      #   User.search(:teenager => true)
+      #
+      # You would expect that to work, but how does Searchlogic::Search tell the difference between your
+      # 'teenager' method and the 'destroy_all' method. It can't, there is no way to tell unless we actually
+      # call the method, which we obviously can not do.
+      #
+      # The being said, we need a way to tell searchlogic that this is method is safe. Here's how you do that:
       #
       #   User.alias_scope :teenager, lambda { age_gte(13).age_lte(19) }
       #
-      # It fits in better, at the same time Searchlogic will know this is an acceptable named scope.
+      # This feels better, it feels like our other scopes, and it provides a way to tell Searchlogic that this
+      # is a safe method.
       def alias_scope(name, options = nil)
         alias_scopes[name.to_sym] = options
         (class << self; self end).instance_eval do
@@ -42,12 +44,14 @@ module Searchlogic
           end
         end
       end
+      alias_method :scope_procedure, :alias_scope
       
       def alias_scopes # :nodoc:
         @alias_scopes ||= {}
       end
       
       def alias_scope?(name) # :nodoc:
+        return false if name.blank?
         alias_scopes.key?(name.to_sym)
       end
       

data/lib/searchlogic/named_scopes/association_conditions.rb

@@ -1,47 +1,19 @@
 module Searchlogic
   module NamedScopes
-    # Handles dynamically creating named scopes for associations.
+    # Handles dynamically creating named scopes for associations. See the README for a detailed explanation.
     module AssociationConditions
       def condition?(name) # :nodoc:
-        super || association_condition?(name) || association_alias_condition?(name)
-      end
-      
-      def primary_condition_name(name) # :nodoc:
-        if result = super
-          result
-        elsif association_condition?(name)
-          name.to_sym
-        elsif details = association_alias_condition_details(name)
-          "#{details[:association]}_#{details[:column]}_#{primary_condition(details[:condition])}".to_sym
-        else
-          nil
-        end
-      end
-      
-      # Is the name of the method a valid name for an association condition?
-      def association_condition?(name)
-        !association_condition_details(name).nil?
-      end
-      
-      # Is the ane of the method a valie name for an association alias condition?
-      # An alias being "gt" for "greater_than", etc.
-      def association_alias_condition?(name)
-        !association_alias_condition_details(name).nil?
-      end
-      
-      # A convenience method for creating inner join sql to that your inner joins
-      # are consistent with how Active Record creates them.
-      def inner_joins(association_name)
-        ActiveRecord::Associations::ClassMethods::InnerJoinDependency.new(self, association_name, nil).join_associations.collect { |assoc| assoc.association_join }
+        super || association_condition?(name)
       end
       
       private
+        def association_condition?(name)
+          !association_condition_details(name).nil?
+        end
+        
         def method_missing(name, *args, &block)
-          if details = association_condition_details(name)
-            create_association_condition(details[:association], details[:column], details[:condition], args)
-            send(name, *args)
-          elsif details = association_alias_condition_details(name)
-            create_association_alias_condition(details[:association], details[:column], details[:condition], args)
+          if !local_condition?(name) && details = association_condition_details(name)
+            create_association_condition(details[:association], details[:condition], args)
             send(name, *args)
           else
             super
@@ -49,29 +21,24 @@ module Searchlogic
         end
         
         def association_condition_details(name)
-          associations = reflect_on_all_associations.collect { |assoc| assoc.name }
-          if !local_condition?(name) && name.to_s =~ /^(#{associations.join("|")})_(\w+)_(#{Conditions::PRIMARY_CONDITIONS.join("|")})$/
-            {:association => $1, :column => $2, :condition => $3}
-          end
-        end
-        
-        def create_association_condition(association_name, column, condition, args)
-          named_scope("#{association_name}_#{column}_#{condition}", association_condition_options(association_name, "#{column}_#{condition}", args))
-        end
-        
-        def association_alias_condition_details(name)
-          associations = reflect_on_all_associations.collect { |assoc| assoc.name }
-          if !local_condition?(name) && name.to_s =~ /^(#{associations.join("|")})_(\w+)_(#{Conditions::ALIAS_CONDITIONS.join("|")})$/
-            {:association => $1, :column => $2, :condition => $3}
+          assocs = reflect_on_all_associations.reject { |assoc| assoc.options[:polymorphic] }.sort { |a, b| b.name.to_s.size <=> a.name.to_s.size }
+          return nil if assocs.empty?
+          
+          if name.to_s =~ /^(#{assocs.collect(&:name).join("|")})_(\w+)$/
+            association_name = $1
+            condition = $2
+            association = reflect_on_association(association_name.to_sym)
+            klass = association.klass
+            if klass.condition?(condition)
+              {:association => $1, :condition => $2}
+            else
+              nil
+            end
           end
         end
         
-        def create_association_alias_condition(association, column, condition, args)
-          primary_condition = primary_condition(condition)
-          alias_name = "#{association}_#{column}_#{condition}"
-          primary_name = "#{association}_#{column}_#{primary_condition}"
-          send(primary_name, *args) # go back to method_missing and make sure we create the method
-          (class << self; self; end).class_eval { alias_method alias_name, primary_name }
+        def create_association_condition(association, condition, args)
+          named_scope("#{association}_#{condition}", association_condition_options(association, condition, args))
         end
         
         def association_condition_options(association_name, association_condition, args)
@@ -83,35 +50,52 @@ module Searchlogic
           if !arity || arity == 0
             # The underlying condition doesn't require any parameters, so let's just create a simple
             # named scope that is based on a hash.
-            options = scope.proxy_options
-            options[:joins] = options[:joins].blank? ? association.name : {association.name => options[:joins]}
+            options = scope.scope(:find)
+            prepare_named_scope_options(options, association)
             options
           else
-            # The underlying condition requires parameters, let's match the parameters it requires
-            # and pass those onto the named scope. We can't use proxy_options because that returns the
-            # result after a value has been passed.
-            proc_args = []
-            if arity > 0
-              arity.times { |i| proc_args << "arg#{i}"}
-            else
-              positive_arity = arity * -1
-              positive_arity.times do |i|
-                if i == (positive_arity - 1)
-                  proc_args << "*arg#{i}"
-                else
-                  proc_args << "arg#{i}"
-                end
-              end
-            end
+            proc_args = arity_args(arity)
+            arg_type = (scope_options.respond_to?(:searchlogic_arg_type) && scope_options.searchlogic_arg_type) || :string
+            
             eval <<-"end_eval"
-              searchlogic_lambda(:#{scope_options.searchlogic_arg_type}) { |#{proc_args.join(",")}|
-                options = association.klass.named_scope_options(association_condition).call(#{proc_args.join(",")})
-                options[:joins] = options[:joins].blank? ? association.name : {association.name => options[:joins]}
+              searchlogic_lambda(:#{arg_type}) { |#{proc_args.join(",")}|
+                scope = association.klass.send(association_condition, #{proc_args.join(",")})
+                options = scope ? scope.scope(:find) : {}
+                prepare_named_scope_options(options, association)
                 options
               }
             end_eval
           end
         end
+        
+        # Used to match the new scopes parameters to the underlying scope. This way we can disguise the
+        # new scope as best as possible instead of taking the easy way out and using *args.
+        def arity_args(arity)
+          args = []
+          if arity > 0
+            arity.times { |i| args << "arg#{i}" }
+          else
+            positive_arity = arity * -1
+            positive_arity.times do |i|
+              if i == (positive_arity - 1)
+                args << "*arg#{i}"
+              else
+                args << "arg#{i}"
+              end
+            end
+          end
+          args
+        end
+        
+        def prepare_named_scope_options(options, association)
+          options.delete(:readonly) # AR likes to set :readonly to true when using the :joins option, we don't want that
+          
+          if options[:joins].is_a?(String) || array_of_strings?(options[:joins])
+            options[:joins] = [inner_joins(association.name), options[:joins]].flatten
+          else
+            options[:joins] = options[:joins].blank? ? association.name : {association.name => options[:joins]}
+          end
+        end
     end
   end
 end