Commited to bedecfc, but I think it's not correct:

not_blank should be

column != "" AND column IS NOT NULL

You see, AND instead of OR. Otherwise, the result set includes empty strings.

Cool, this has been added

You're quite right about that. I rewrote the spec for non_blank to be a little bit more clear. Here's the new patch:

http://gist.github.com/174204

Granted, I think that just saying column != '' will have the same results, since I believe NULL values won't even be considered in a string comparison. I left it as you suggested though for completeness' sake.

Great, thanks!

Hm, this issue show be re-opened until Ben has commited the patch...

Thanks, this has been fixed.

Yeah, that's definitely doable. I'll throw something together for that.

Thanks!

This has been added. It was actually pretty fun to code. Anyways, checkout the readme for some examples, or checkout the specs:

http://github.com/binarylogic/searchlogic/blob/24bc3715a2baf3a21ae95d0d7d7d8f2868503458/spec/named_scopes/or_conditions_spec.rb

Let me know if you have any issues.

This works for me in a simple case like

Address.first_or_last_like("something")

but im having problems with associations:

#Customer => has_many addresses
Customer.address_first_or_address_last_like("something")
# => error: The condition 'address_first' is not a valid condition, we could not find any scopes that match this.
Customer.address_first_like_or_address_last_like("something")
# => error: The condition 'address_last_like' is not a valid condition, we could not find any scopes that match this

Also (im not sure why i was trying this) but this gave me a stack level too deep:

Customer.address_first_like_or_id_equals(0)

Details;
User.ascend_by_role_is_admin
in that case the query is;
User Load (1.5ms) SELECT "users".* FROM "users" INNER JOIN "roles" ON roles.user_id = users.id ORDER BY roles.is_admin ASC

whereas I need LEFT JOIN in the query for getting all records but order by is_admin field.

I have this same problem in my application. There is no easy way around this. Your best bet is to write your own order condition that uses the same join so that AR will remove the duplicates. The other option is to give your left outer joins aliases like "optional_roles". This is what I've been doing in my apps. This really isn't an issue with SL directly, its more of an issue with just combining named scopes. If you want to modify the join that SL creates, you are better off just creating the named scope yourself and adding the join that you want.

Thanks.

Can you please create a failing test for this. It would be much easier. I couldn't reproduce any problems with the app. Thank you.

The app give the expected results to me as well.
The only confusing part is that some of your items names start by a capital and not some others so can look failling at a first look while it give the expected result.

Sorting on a single table Help

I have no idea. Can you please create a failing test, and then I can fix the issue. By test, I mean a test I can run in the searchlogic test suite. I apologize for asking you to do this, but its a new policy I am implementing with my open source projects. I am just very busy and this would help me easily knock out the issue.

by Ben Johnson

Sorting on a single table Help

Wilco, but I need time, since I am a newbie

by ramesh

Sorting on a single table Help

Will this help ?

When I use :-
"@search = ArdData.new_search(params[:search]);" in the controller the sql generated on sorting any column is :- "Processing ArdDataController#index (for 127.0.0.1 at 2009-04-01 18:01:17) [GET] Parameters: {"search"=>{"order_as"=>"ASC", "order_by"=>"stock"}} ArdData Columns (2.1ms) SHOW FIELDS FROM ard_datas ArdData Load (0.2ms) SELECT * FROM ard_datas ORDER BY ard_datas.stock ASC LIMIT 25 SQL (0.1ms) SELECT count(ard_datas.part_number) AS count_part_number FROM ard_datas Rendering ard_data/index
Completed in 46ms (View: 23, DB: 3) | 200 OK [http://localhost/ard_data?search%5Border_as%5D=ASC&search%5Border_by%5D=stock]"

Here I have tried sorting on the "Stock" column. This works for other columns also.

When I use:-

"@search = ArdData.new_search(:conditions => {:store_type => ’DOR’, :cpq_category => ’P’});" in the controller the sql generated on sorting any column is :-

"Processing ArdDataController#index (for 127.0.0.1 at 2009-04-01 19:24:09) [GET] Parameters: {"search"=>{"order_as"=>"ASC", "order_by"=>"stock"}} ArdData Columns (2.1ms) SHOW FIELDS FROM ard_datas ArdData Load (0.2ms) SELECT * FROM ard_datas WHERE (ard_datas.cpq_category = ’P’ AND ard_datas.store_type = ’DOR’) LIMIT 25 SQL (0.6ms) SELECT count(ard_datas.part_number) AS count_part_number FROM ard_datas WHERE (ard_datas.cpq_category = ’P’ AND ard_datas.store_type = ’DOR’) Rendering ard_data/index
Completed in 73ms (View: 28, DB: 3) | 200 OK [http://localhost/ard_data?search%5Border_as%5D=ASC&search%5Border_by%5D=stock]"

The difference I see is in the "ArdData Load". The first query(no conditions) has a "ORDER BY" clause whereas the second(with conditions) doesn’t.

by ramesh

Sorting on a single table Help

Sorry for the lack of activity, is this still an issue. It looks like this bug is for the older version of searchlogic.

by Ben Johnson

Guess not, thanks!

Problem with Multiple Conditions on STI Models

You could do:

Ride.make_name_equals_any("Chevrolet", "Tahoe")

Does that fix the issue?

by Ben Johnson

Problem with Multiple Conditions on STI Models

Well it would have to be make_model_name, but I would have to have an association to make_model, which given it’s a STI, isn’t really easy to do... since... well, hopefully you can see why...

Only way I’d get this to work is splitting the STI, which i can do... would mean more maintenance, but it would fix this issue...

I was trying to do this using a "filter" method i created based off the order method you provide..

@@@ ruby def filter(search, options = {}, html_options = {})

  options[:params_scope] ||= :search
  options[:as] ||= options[:by].to_s.humanize
  options[:filter_scope] ||= "#{options[:by]}"
  new_scope = options[:filter_scope]
  link_to options[:as], url_for(options[:params_scope] => search.conditions.merge( { "#{options[:on]}_like" => new_scope } ) ), html_options
end

@@@

Where it would work like your order, just append search conditions based on links that a user can select from a list

by omarvelous

Bug: Problems with multiple scopes beginning with the same name

I am trying to create a failing test for this in my test suite and can’t seem to do it. Do you mind giving that a shot. I am 90% certain this has to do with the order of keywords in the regular expression. Ex:

/(documents|documents_involved)/

When it should be

/(documents_involved|documents)/

This is a really easy fix, but I want to get a failing test in place first.

by Ben Johnson

Bug: Problems with multiple scopes beginning with the same name

This has got a little bit more complicated because the bug has changed since searchlogic 2.3.3. Now it occurs not every time. I can’t reproduce it and can’t write a failing test, sorry. But it seems that it has something to do with other calls to Contact.search BEFORE - very strange.

But I have found a very similar issue, perhaps they are related. Here is a small patch for the specs (just add one line) and the specs will fail:

@@@ diff --git a/vendor/plugins/searchlogic/spec/spec_helper.rb b/vendor/plugins/searchlogic/spec/spec_helper.rb
index a2b98f0..c155938 100644
--- a/vendor/plugins/searchlogic/spec/spec_helper.rb +++ b/vendor/plugins/searchlogic/spec/spec_helper.rb @@ -71,6 +71,7 @@ Spec::Runner.configure do |config|

 class User < ActiveRecord::Base
   belongs_to :company, :counter_cache => true
   has_many :orders, :dependent => :destroy

• has_many :orders_big, :class_name => ’Order’, :conditions => ’total > 100’ end

  class Order < ActiveRecord::Base @@@

by Georg Ledermann

Seems to be fixed by c8547d5. Thanks!

Thanks

Inconsistent result of "order" method

You make a good point here, but for your examples to pass it would change the underlying logic behind the Search class. The point is just to store values that map to a named scope. So "decend_by_datetime" and :order => "descend_by_datetime" are 2 different named scoped. The order named scope is really just an alias that calls other named scopes. The whole point of it is to make searching with the search object easier. My suggestion is to use "order" when dealing with the search object, and if you aren’t you can do whatever you want.

What do you think?

by Ben Johnson

Inconsistent result of "order" method

I’m trying to understand, hm, but there is still something confusing if I want to get the order of an existing search object. I find out that using proxy_options gives better result:

@@@ ruby

Document.search("descend_by_datetime" => true).proxy_options[:order] => "documents.datetime DESC" # OK!

Document.search("descend_by_datetime" => true).construct_finder_sql({}) => "SELECT * FROM documents ORDER BY documents.datetime DESC" # OK! @@@

@@@ ruby

Document.search(:order => "descend_by_datetime").proxy_options[:order] => "documents.datetime DESC" # OK!

Document.search(:order => "descend_by_datetime").construct_finder_sql({}) => "SELECT * FROM documents ORDER BY documents.datetime DESC" # OK! @@@

But what is this?
@@@ ruby

Document.search(:order => "datetime DESC").order => "datetime DESC" # OK!

Document.search(:order => "datetime DESC").proxy_options => {} # ???

Document.search(:order => "datetime DESC").construct_finder_sql({}) => "SELECT * FROM documents " # ??? @@@

You see that the proxy_options are blank and the last SQL statement has no ORDER BY.
Maybe I’m the only one who is confused, maybe it’s because I’m going on holiday tomorrow ;-)

Best wishes,
Georg

by Georg Ledermann

Inconsistent result of "order" method

That’s because the :order condition MUST be a named scope, you can’t pass raw SQL.

by Ben Johnson

Inconsistent result of "order" method

Also, this is to protect from SQL injections

by Ben Johnson

Inconsistent result of "order" method

Ok, totally agree. To avoid irritations, what about raising an exception (like "UnknownOrderError") if someone gives raw SQL (or unknown order scope) to the :order key? I think this would be a good thing, because there is already a Searchlogic::Search::UnknownConditionError raised for wrong :condition value.

by Georg Ledermann

Just add the table name to the default scopes order, its kind of uggly but it works.

default_scope :order => "companies.name"

for example.

Yeah, kalas has it right. Thanks.

it's already fixed for 2.0.2. See http://github.com/binarylogic/searchlogic/commit/c2c7c9374deeb9cb6ccaa072d795a4f1985df00d

Thanks.

why you need to use true or false? Just use ascend_by_name or descend_by_name and you will be fine.

Im not sure what the question is.

Thats a good idea, I will see what I can do to get this in there.

+1 -- I've been scratching my head on this one for a while. The scope works in my console when I run it directly, but in the app - which involves searchlogic - the scope doesn't work.

named_scope :occurred_at_between, lambda {|*args| {:conditions => ["alerts.occurred_at >= ? AND alerts.occurred_at <= ?", (args.first), (args.last)]}}

This works in the console, but when added to a search object, it only gets one parameter.

The problem is that the values sent from the form can only be strings, arrays, or hashes. You can't send ranges, etc. In the console this is dioble, but to have range support directly from the params hash is not possible. The only solution is to send an array to the scope and use the first and last values. You could also create an alias scope that handled a single value and translated to whatever scope you wanted to use.

That's generally true, but it is entirely possible that a custom param parser is being used.

For instance, I use http://github.com/laserlemon/search_party which gives me search_params containing arrays, ranges, money objects, floats, etc.

Also, searchlogic is obviously much more useful than just passing params to named_scopes. The collection of scopes it adds to the picture are half the fun. In my case, I needed to pass a possible range value to a scope that queried a model's association. I really would rather not reinvent the wheel as far as the association support that's already been built in.

I forked and addressed the issue using AR's existing attribute_condition and expand_range_bind_variables methods, so the behavior is consistent.

I agree, thanks a lot for your commits I applied them.

SL 2.0 trimmed a lot of fat, because of this no configuration is needed as of yet. Any helper configuration is passed to the helper directly, and the only helper present is order.

also posted on lighthouse:
http://binarylogic.lighthouseapp.com/projects/16601/tickets/92-conflict-with-a-scope-on-a-column-beginning-with-the-name-of-an-association

Has anyone got a quick fix for this? I would love to have it!!

This has been fixed, let me know if you have any other issues.

Thanks for fixing this, i had the exact same problem.

Bigtime. I've run into this with LIKE, and got suspicious results (duplicated rows) when I tried it myself across a join.

This has been in searchlogic for a couple of weeks now, sorry for not noticing this. But you should be good to go.