freelancing-god / thinking-sphinx
- Source
- Commits
- Network (161)
- Issues (17)
- Graphs
-
Branch:
master
-
0 votes
0 comments Created 8 days ago by freelancing-godRiddle version warning on app server when sphinx is on a different server.bugxSee http://groups.google.com/group/thinking-sphinx/browse_thread/thread/5ebb550ae7cd690c
Riddle version check fails on app server, because Sphinx is running on a different server. We need some way of explicitly telling Thinking Sphinx which version of Sphinx is being used.
Comments
-
0 votes
3 comments Created 2 months ago by akeiaabstract model class leads to sql-join with non-existent tablebugxif a model class has a parent class that is abstract (self.abstract_class = true) ts sees the class as full model class and tries to join with non-existent table in generated sql.
Comments
freelancing-god
Mon Nov 16 19:56:21 -0800 2009
| link
Might be able to look at this issue soon, so I just want to clarify: in which model is the define_index statement, what does it look like, and which associations used by the define_index block (if any) refer to models with abstract parents?
there are issues with abstract classes in ActiveRecord.... try to use 'reflections' method on inherited class and on abstract class. some of the assosiations are not included and TS is using that method for query generation.
freelancing-god
Thu Dec 10 21:18:55 -0800 2009
| link
Hi Bartosz - thanks for the feedback, but I can't figure out how to reproduce this issue. I just added a new feature to the cucumber tests in Thinking Sphinx - feel free to have a look and see what I could be doing differently: 695edea
-
This is a re-post of a previous issue. I just now realized that the previous fix successfully removed the error, but still doesn't seem to return correct results when scoped.
# Model code... class Publication < ActiveRecord::Base has_many :issues has_many :articles, :through => :issues end class Issue < ActiveRecord::Base belongs_to :publication has_many :articles end class Article < ActiveRecord::Base belongs_to :issue define_index do has issue(:publication_id), :as => :publication_id end sphinx_scope(:web_content) { { :order => 'release_date DESC', :without => {:release => 0} # sphinx stores null as 0 } } endWhat I've observed is the following:
publication = Publication.find(1) publication.articles.search 'foobar' # returns only results in publication - correct behavior publication.articles.web_content # returns web content articles from both publications - incorrect behavior Article.web_content.search :with => {:publication_id => 1} # returns web content articles from publication 1 - correct behavior, and a functional workaround, but no funComments
-
class Product belongs_to :category define_index do has category(:id), :as => :category_ids, :source => :query end endGenerates:
sql_attr_multi = uint category_ids from query; SELECT `categories`.`category_id` * 1 + 0 AS `id`, `categories`.`id` AS `category_ids` FROM `categories`
categoriesin categories.category_id should beproducts.Comments
-
0 votes
7 comments Created about 1 month ago by jamese:source => :field|:query|:ranged_query with :facet => true messed upbugxI'm almost positive this was working for me on Friday, so I'm confused... now if I add the :facet => true to :query an error. I'm defining this like:
has "SELECT products.id * 1 + 0 AS id, c1.id AS category_ids FROM products LEFT JOIN categories ON products.category_id = categories.id LEFT OUTER JOIN `categories` c1 ON `categories`.lft BETWEEN `c1`.lft AND `c1`.rgt", :as => :category_ids, :source => :query, :facet => true
When I try the same thing but with
:source => :ranged_queryand:facet => true, it generates an extracategory_ids_facetattribute!?This is the error I get:
NoMethodError: undefined method `SELECT products.id * 1 + 0 AS id, c1.id AS category_ids FROM products LEFT JOIN categories ON products.category_id = categories.id LEFT OUTER JOIN `categories` c1 ON `categories`.lft BETWEEN `c1`.lft AND `c1`.rgt' for # from /usr/lib/ruby/gems/1.9.1/gems/activerecord-2.3.5/lib/active_record/attribute_methods.rb:260:in `method_missing' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet.rb:102:in `translate' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet.rb:75:in `value' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet_search.rb:114:in `block in add_from_results' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/search.rb:196:in `block in each_with_groupby_and_count' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/search.rb:195:in `each' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/search.rb:195:in `each_with_index' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/search.rb:195:in `each_with_groupby_and_count' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet_search.rb:113:in `add_from_results' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet_search.rb:49:in `block in populate' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet_search.rb:47:in `each' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet_search.rb:47:in `populate' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/facet_search.rb:13:in `initialize' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/search_methods.rb:422:in `new' from /usr/lib/ruby/gems/1.9.1/gems/thinking-sphinx-1.3.7/lib/thinking_sphinx/search_methods.rb:422:in `facets' from (irb):1 from /usr/bin/irb:12:in `'>>Comments
Apparently I had modified TS source to override the default behaviour of trying to determine types on it's own for facets, which is why I had it working. Wouldn't it be a lot easier to just leave type defining up to the developer??? Have a
:multioption separate from:type.define_index do |i|
i.string description i.integer "SELECT ... FROM ...", :source => :query endForget compatibility... make TS rock! :D
Sorry, I see :multi as a type is consistant with what Sphinx uses.
I'm really trying to understand the TS code better... correct me if I'm wrong, but I'm thinking the problem is in facet.rb, and with the
translatemethods?What is attribute.rb doing right, that facet.rb is doing wrong... if defining the attribute works correctly, then why can't the facet.rb code do the same?
Okay, I think I've got it? translate? in facet.rb checks whether the column is integers using all_ints?. This could be fixed by also checking is_many_ints?, but these checks shouldn't be needed at all, since it was already determined in attribute.rb, so we should trust the checks done in there and not duplicate code:
diff --git a/lib/thinking_sphinx/facet.rb b/lib/thinking_sphinx/facet.rb index 393fc83..e47b681 100644 --- a/lib/thinking_sphinx/facet.rb +++ b/lib/thinking_sphinx/facet.rb @@ -47,7 +47,7 @@ module ThinkingSphinx when :integer, :boolean, :datetime, :float false when :multi - !property.all_ints? + false end endScratch that, I guess the whole purpose of facet.rb is to allow string facets, so that check for all_ints? is needed :)
I'm lost...
Hey Pat, how about something like this:
diff --git a/lib/thinking_sphinx/facet.rb b/lib/thinking_sphinx/facet.rb index 393fc83..268d479 100644 --- a/lib/thinking_sphinx/facet.rb +++ b/lib/thinking_sphinx/facet.rb @@ -38,7 +38,11 @@ module ThinkingSphinx end end + # Determine whether to translate the property into an attribute to allow + # faceting on strings or their crc'd copy. Translation is not available + # on string columns because we are not able to determine the type. def self.translate?(property) + return false if property.columns.any? {|c| c.is_string? } return true if property.is_a?(Field) case property.typeIf there was a way to explicitely specify the type for string/sql columns, then translating could potentially work. But if someone is going to be using string columns then they're also going to know how to CRC() stuff themselves.
Sorry for all the noise. :)
Oh man, you're going to hate me! How about something like this :) I'm not sure if it's okay to just make a method not private anymore? Also, for something this small, would you still want me to do a pull request?
diff --git a/lib/thinking_sphinx/facet.rb b/lib/thinking_sphinx/facet.rb index 393fc83..bc73137 100644 --- a/lib/thinking_sphinx/facet.rb +++ b/lib/thinking_sphinx/facet.rb @@ -38,6 +38,9 @@ module ThinkingSphinx end end + # Determine if the property should be translated into an attribute. + # Multi-value string/SQL columns are not translated because there is no + # way to determine the type. def self.translate?(property) return true if property.is_a?(Field) @@ -47,7 +50,7 @@ module ThinkingSphinx when :integer, :boolean, :datetime, :float false when :multi - !property.all_ints? + !(property.all_ints? || property.is_string?) end end diff --git a/lib/thinking_sphinx/property.rb b/lib/thinking_sphinx/property.rb index 24ae8be..f544f7f 100644 --- a/lib/thinking_sphinx/property.rb +++ b/lib/thinking_sphinx/property.rb @@ -76,6 +76,12 @@ module ThinkingSphinx !admin end + # Returns true if any of the columns are string values, instead of database + # column references. + def is_string? + columns.all? { |col| col.is_string? } + end + private # Could there be more than one value related to the parent record? If so, @@ -85,12 +91,6 @@ module ThinkingSphinx associations.values.flatten.any? { |assoc| assoc.is_many? } end - # Returns true if any of the columns are string values, instead of database - # column references. - def is_string? - columns.all? { |col| col.is_string? } - end - def adapter @adapter ||= @model.sphinx_database_adapter end @@ -159,4 +159,4 @@ module ThinkingSphinx assocs end end -end \ No newline at end of file +end -
It drops out with:
`require': no such file to load -- action_controller/dispatcher (MissingSourceFile)The problem appears in init.rb where you require it.
Comments
-
2 votes
0 comments Created 2 months ago by myronmarstonfeaturexIn a define_index block, provide a way to force a join in the generated SQLrestructurexThis is needed when you want to define an attribute using a SQL fragment that references a column in another table. Current work around is to define an attribute on a column in the other table using the association in your model, but this isn't a very elegant solution, especially when you don't want the additional attribute.
An example of a real-world need for this can be found in this post from the google group.
Comments
-
1 vote
1 comment Created 5 months ago by seanabrahamsbugx:with time range not workingintermittentxI have some items that are updated periodically and I use the :with functionality to only show results from updated items. However, the behavior has been unpredictable and not working.
At times it returns no results when it should. Other times it returns results when it shouldn't.
define_index do indexes title, :sortable => :true indexes description indexes retailer(:name), :as => :retailer_name # attributes that are not strings has retailer_id, created_at, updated_at set_property :delta => true endand
Item.search 'search terms', :match_mode => :all, :field_weights => { :title => 20, :description => 5 }, :with => { :updated_at => 1.day.ago..Time.now }Comments
This may very well be time issue with sphinx and mysql. Sphinx converts all date times into a unix timestamp integer. Sphinx does this by using the UNIX_TIMESTAMP function in MySQL.
The caveat is that if your application is storing all times in UTC. The UNIX_TIMESTAMP function (http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function_unix-timestamp) interprets any date given in its current timezone (which is usually SYSTEM).
Long story short, it is taking an already converted UTC time and converting it again. The way to get around this is to specify a sql_query_pre option in the sphinx.yml file to set the timezone to UTC during indexing. That way the UNIX_TIMESTAMP function will make no UTC offset adjustments
sql_query_pre: - "SET TIME_ZONE = '+0:00'"
-
0 votes
9 comments Created 3 months ago by jamesefeaturexCalling Model.facets results in numerous SQL database queriesrestructurexCalling Model.facets results in SQL database queries even though it returns a hash of facets. Thinking Sphinx should be able to return the facets as stored in the Sphinx database.
Comments
Sorry, I just noticed issue #17. Maybe you could store the crc32, as well store a field with the value? Long shot I'm sure...
freelancing-god
Thu Oct 01 15:42:18 -0700 2009
| link
Not sure what you mean by storing the field... Sphinx doesn't return any field information, and the CRC is what is being returned, but we can't reverse that, so there's no way (that I can think of) for avoiding database calls.
Ideally, it should only make the call when it needs to, so there is room for improvement. I'll leave this ticket open as a reminder for that.
Ya, sorry that didn't make a lot of sense. I imagine this problem will be solved when Sphinx can store string attributes as strings (this is planned right?).
What I was thinking about and didn't write clearly is that you have this sphinx document data, so why not make it available. Then you could use the document data and not hit the database unless you really need to. So, say you search using the CRC, but then display another indexed string associated with the docid.
freelancing-god
Fri Oct 02 03:00:22 -0700 2009
| link
Yeah, string attributes are planned for 0.9.10, from what I've read - although plenty of people are still using 0.9.8 at the moment.
Still unclear on your suggestion though... what do you mean by 'another indexed string associated with the docid'?
I'm horrible at explaining things :) I'll try again...
Say you have the following document data in your sphinx database (using a Hash
to represent document fields/attributes):
[{:color_crc => "3632233996", :color_text => "Blue"}, {:color_crc => "3632233997", :color_text => "Indigo Blue"}, {:color_crc => "3632233998", :color_text => "Baby Blue"}]When you search or retrieve the facets, you do:
@results = Model.search(:with => "Blue".to_crc32) @facets = Model.search(@results.options)
In this case, you'd match the first document, which has {:color_text => "Blue"}
associated with it. What I'm wondering is, would it be possible to use
the associated document data instead of pulling everything from MySQL,
PostgreSQL, etc? So instead of performing a query to get "Blue", you could
just get it from the sphinx document by accessing :color_text?Maybe when defining your indexes you could do something like:
define_index do indexes colors.name, :as => :color_text has "CRC32(colors.name)", :as => :color, :type => :integer, :text => :color_text end
Am I totally mis-understanding how Sphinx works? Or, does this make any more
sense?
freelancing-god
Fri Oct 02 08:17:17 -0700 2009
| link
Okay, makes sense now :)
However, Sphinx doesn't return field information, it just returns attributes - and thus, no string data. Otherwise, would definitely have no need for any database queries in facet searching.
Interesting... so Sphinx is purposefully very dependent on SQL, both to index, and to provide the actual document data?
Well, I guess when Sphinx gets string attributes, it'll be a good day! Or, you could always try figuring out how to reverse CRC32 ;)
http://www.woodmann.com/fravia/crctut1.htm
freelancing-god
Fri Oct 02 09:03:52 -0700 2009
| link
Ouch, assembly code. Still, maybe I'll find the time and patience to convert it to Ruby :) thanks for the link.
And yeah, Sphinx is very much focused on returning a minimal data set for each result, and letting you decide what you want to do with it.
Just a different take on this. Since Thinking Sphinx is spending the time to query the database for the string data, could it make the model instance available instead of just a string? This may be desireable even when Sphinx does get string attributes. Take a Category model for example. If the instance is available, then you could get depth information. You could also store the id, but display something totally different.
-
Is there a way to reuse the same scope for search and for
facet search?Here is example what I mean (from online tutorial)..
scope = Article.latest_first.by_name('Puck')
articles = scope.search
facets = scope.facetsComments
datenimperator
Mon Aug 17 07:07:02 -0700 2009
| link
+1
That'd be great and very useful. In the meantime, the following seems to work without too much fuss:
_projects = Project.latest_first _projects = _projects.by_location(params[:location_name]) if params[:location_name] @facets = Project.facets @query, _projects.options @projects = _projects.search @query, :page => @page, :per_page => 10 -
Xapit has a very convenient solution for facet url creation, which allows you to get your faceting up and running extremely fast (it just works):
From http://github.com/ryanb/xapit
BEGIN QUOTE
Facets allow you to further filter the result set based on certain attributes.
<% for facet in @articles.facets %> <%= facet.name %> <% for option in facet.options %> <%= link_to option.name, :overwrite_params => { :facets => option } %> (<%= option.count %>) <% end %> <% end %>The to_param method is defined on option to return an identifier which will be passed through the URL. Use this in the search.
Article.search("phone", :facets => params[:facets])You can also list the applied facets along with a remove link.
<% for option in @articles.applied_facet_options %> <%=h option.name %> <%= link_to "remove", :overwrite_params => { :facets => option } %> <% end %>END QUOTE
Their to_param implementation allows it to work for both adding the facet if it doesn't exist, and if it does exist, then depending on breadcrumb_facets? will either remove just that facet, or remove all back to a given facet (breadcrumb_facets? == true):
http://github.com/ryanb/xapit/blob/master/lib/xapit/facet_option.rbOne downside to this implementation is that it doesn't allow you to have breadcrumb navigation links and a remove facet link.
Shop > Shoes (X) > Blue[breadcrumb mode] (X)[remove mode]
It would be nice to be able to configure this "on the fly":
<% for option in @articles.applied_facet_options %> <%= link_to option.name, :overwrite_params => { :facets => option } %> <%= link_to "remove", :overwrite_params => { :facets => option.remove } %> <% end %>Having the facet params encoded as a single param enables the breadcrumbs to be displayed in the order the user selects them. This means you don't have to use cookies, etc. to track this ordering. It also means that the controller code is very simple and just has to pass a single param into the Model.search options.
What do you think? :D
Comments
-
I am getting an undefined method error for sphinx_scope
I am using ruby enterprise version 1.8.6-20090421this is what is in my environment.rb
config.gem( 'freelancing-god-thinking-sphinx', :lib => 'thinking_sphinx', :version => '1.2.9', :source => 'http://gems.github.com' )
config.gem 'mislav-will_paginate', :version => '~> 2.3.11', :lib => 'will_paginate',
:source => 'http://gems.github.com'here's my gem list actionmailer (2.3.3, 2.3.2)
actionpack (2.3.3, 2.3.2)
activerecord (2.3.3, 2.3.2)
activeresource (2.3.3, 2.3.2)
activesupport (2.3.3, 2.3.2)
capistrano (2.5.8)
cassandra (0.5.6.2)
cgi_multipart_eof_fix (2.5.0)
daemons (1.0.10)
fastthread (1.0.7)
freelancing-god-thinking-sphinx (1.2.9)
gem_plugin (0.2.3)
haml (2.2.3)
highline (1.5.1)
hpricot (0.8.1)
htmldoc (0.2.1)
httpclient (2.1.5.2)
image_science (1.2.1)
json (1.1.9)
memcached (0.16.3)
mislav-will_paginate (2.3.11)
mms2r (2.3.0)
mongrel (1.1.5)
mysql (2.7)
net-scp (1.0.2)
net-sftp (2.0.2)
net-ssh (2.0.15)
net-ssh-gateway (1.0.1)
passenger (2.2.5, 2.2.1)
postgres (0.7.9.2008.01.28)
rack (1.0.0, 0.9.1)
rails (2.3.3, 2.3.2)
rake (0.8.4)
RubyInline (3.8.3)
soap4r (1.5.8)
sqlite3-ruby (1.2.4)
thrift (0.0.810255.1)
tmail (1.2.3.1)
ZenTest (4.1.4)
and here's the stack trace
=> Booting Mongrel => Rails 2.3.3 application starting on http://0.0.0.0:3000 /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activerecord-2.3.3/lib/active_record/base.rb:1959:in
method_missing_without_paginate': undefined methodsphinx_scope' for #<Class:0x3913590> (NoMethodError)from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/mislav-will_paginate-2.3.11/lib/will_paginate/finder.rb:168:in `method_missing' from /media/disk/var/www/xoonoo.com/current/app/models/user.rb:98 from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:380:in `load_without_new_constant_marking' from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:380:in `load_file' from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:in `new_constants_in' from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:379:in `load_file' from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:259:in `require_or_load' from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:425:in `load_missing_constant' ... 35 levels... from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/rails-2.3.3/lib/commands/server.rb:84 from /opt/ruby-enterprise/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /opt/ruby-enterprise/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from script/server:3I had this working before but I have just moved to a new workstation and I am trying to setup my environment and now I get this error. Any ideas ?
Comments
freelancing-god
Fri Sep 11 07:55:28 -0700 2009
| link
Not sure what the cause is - is the new workstation the only change? There hasn't been any code changes? I've just tried on my relatively new Snow Leopard setup on Rails 2.3.3 and Mongrel, and it works fine, as far as I can tell.
Completely unrelated, but upgrading to 2.3.4 is recommended, there's a vulnerability in Rails in earlier 2.x versions.
-
0 votes
0 comments Created about 1 month ago by voronovMongrel not start if if thinking sphinx enabled as gem and translation stores in custom folder layout.conflictx=> Booting Mongrel => Rails 2.3.5 application starting on http://0.0.0.0:3000 /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:206:in `deep_symbolize_keys': You have a nil object when you didn't expect it! (NoMethodError) You might have expected an instance of Array.
The error occurred while evaluating nil.inject
from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:197:in `merge_translations' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:177:in `load_file' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:177:in `each' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:177:in `load_file' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:13:in `load_translations' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:13:in `each' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:13:in `load_translations' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:85:in `init_translations' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/vendor/i18n-0.1.3/lib/i18n/backend/simple.rb:74:in `available_locales' from /var/lib/gems/1.8/gems/thinking-sphinx-1.3.7/rails/init.rb:12:in `evaluate_init_rb' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:182:in `call' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:182:in `evaluate_method' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:166:in `call' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:90:in `run' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:90:in `each' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:90:in `send' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:90:in `run' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:276:in `run_callbacks' from /var/lib/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:51:in `send' from /var/lib/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:51:in `run_prepare_callbacks' from /var/lib/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:631:in `prepare_dispatcher' from /var/lib/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:185:in `process' from /var/lib/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /var/lib/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /var/lib/gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /var/lib/gems/1.8/gems/rails-2.3.5/lib/commands/server.rb:84 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from script/server:3Comments
-
1 vote
4 comments Created 11 days ago by jerryvosActiveRecord method chain giving infinite recursionconflictxThis is an odd situation, but is causing my app to blow up, and thought I'd document it here. I'm using wycat's bundler to manage my gems, and am using both thinking-sphinx and the delayed delta extension.
I'm not sure how it's just now happening, but we're getting infinite recursions in Sphinx's reset_subclasses_with_thinking_sphinx method. By doing some logging, I've found we're getting lib/thinking_sphinx.rb required twice, which causes the active record include to run twice, leading to the alias_method_chain running twice, leading to FAIL.
Based on my research, I've found there's a couple things going on leading to this.
1- We're depending on thinking-sphinx as
gem 'thinking-sphinx', '>=1.3.1'Which doesn't cause a require 'thinking_sphinx' to occur. This doesn't cause any issue directly
2- We then require delayed-delta
gem 'ts-delayed-delta', '>= 1.0.0', :require_as => 'thinking_sphinx/deltas/delayed_delta'Inside delayed delta, there are classes being defined as:
class ThinkingSphinx::Deltas::DeltaJobThe fact that it's namespacing like that, instead of saying module X; module Y; class DeltaJob, causes active support to search the class path, eventually leading to lib/thinking_sphinx.rb getting required.
3- Now all this has ran, eventually rails requires rails/init.rb, which again triggers a require 'thinking_sphinx', which for some reason is causing the thinking_sphinx file to again be executed.I'm not sure why this setup is causing 3 to break like it is. I will try and take another pass at gleaning some more information, but wanted to document this while it's fresh and in case anyone else gets it.
A solution is to just make sure when you depend on thinking-sphinx you make sure it gets required as "thinking_sphinx".
The stack trace you'll get will be at reset_subclasses_with_thinking_sphinx and it'll be a SystemStackError.
Comments
I'm seeing this as well with thinking-sphinx 1.3.14, ts-delayed-delta 1.0.2, and rails 2.3.5. I have yet to find a workaround.
Here's some of my stacktrace:
Error calling Dispatcher.dispatch #<SystemStackError: stack level too deep> /usr/lib/ruby/gems/1.8/gems/thinking-sphinx-1.3.14/lib/thinking_sphinx/active_record.rb:64:in `reset_subclasses_without_thinking_sphinx' /usr/lib/ruby/gems/1.8/gems/thinking-sphinx-1.3.14/lib/thinking_sphinx/active_record.rb:64:in `reset_subclasses' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:63:in `cleanup_application' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/reloader.rb:17:in `close' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/cgi_process.rb:62:in `dispatch_cgi' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:101:in `dispatch_cgi' /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:27:in `dispatch'@ajh, how are you referencing thinking sphinx? Are you doing config.gem?
Hi jerryvos,
I'm using config.gem in my environment.rb as described in the docs:
config.gem 'thinking-sphinx', :version => '~> 1.3.14', :lib => 'thinking_sphinx' config.gem 'ts-delayed-delta', :lib => 'thinking_sphinx/deltas/delayed_delta', :version => '>= 1.0.0'You mentioned that you have a solution/workaround. I'd appreciate it if you could elaborate.
All I did to get it working for me was make sure I had thinking-sphinx listed before delayed delta. As a temporary workaround, you could try putting require 'thinking_sphinx' at the top of your environment.rb
Possibly dumb question, but you just have thinking-sphinx as a gem right, not also as a plugin?
-
1 vote
wrong sql when using :include option in has_many/has_one association
1 comment Created 24 days ago by bartesthere is no join table statement
Comments
freelancing-god
Thu Dec 10 21:22:27 -0800 2009
| link
Hi Bartosz
Can you provide an example? This is very much an edge case, so I'm not sure when I'll have this playing nicely with Thinking Sphinx... it may be worth using the underlying associations in the :include argument as part of the index definition, and thus they'll get included anyway?
-
0 votes
Each facet query performs joins regardless whether they're needed
0 comments Created 3 days ago by jamese@facets = Product.facets( :include => {:product_line => :product_brand}, :facets => [:availability, :brand])
The joins will be included in the queries for both :brand and :availability facet values, even though :availability is part of the Product model.
Comments
-
CAST as CHAR truncates string fields greater than 1024 characters (e.g. a field defined using the TEXT type). I'm not sure why CAST as CHAR is even necessary...
Comments
