I am adding the elasticsearch gem to an existing rails app hosted on Heroku.
Running MyModel.import in production is raising an error
MultiJson::ParseError: unexpected character at line 1, column 1 [parse.c:690]
As my development and test environments are working perfectly, I assume that this is being caused by the data in MyModel, perhaps an encoding issue. But as this table is quite large, I am having trouble tracking down the problem.
Can anyone confirm that this error is likely to be caused by an
issue in the data being imported?
Is there a way to inspect the JSON data representation that MyModel.import invokes?
EDIT
Following suggestions below, I have tried running a few commands to track down the error.
MyModel.all.each(&:as_json)
MyModel.all.each(&:as_indexed_json)
MyModel.all.each { |r| r.__elasticsearch__.as_indexed_json }
MyModel.all.each { |r| MultiJson.load r.to_json }
are all running without errors. However they do not appear to be returning json, but arrays of records. Is this usual?
[#<MyModel id: 1, ......
Running import on a limited number of records is also causing strange results.
# a single record returns no error
MyModel.import query: -> { where(id: 1) }
=> 0
# multiple records return the error
MyModel.import query: -> { where(id: 1..2) }
MultiJson::ParseError: unexpected character at line 1, column 1 [parse.c:690]
The full stack trace is
MultiJson::ParseError: unexpected character at line 1, column 1 [parse.c:690]
from /app/vendor/bundle/ruby/2.4.0/gems/multi_json-1.11.3/lib/multi_json/adapters/oj.rb:15:in `load'
from /app/vendor/bundle/ruby/2.4.0/gems/multi_json-1.11.3/lib/multi_json/adapters/oj.rb:15:in `load'
from /app/vendor/bundle/ruby/2.4.0/gems/multi_json-1.11.3/lib/multi_json/adapter.rb:20:in `load'
from /app/vendor/bundle/ruby/2.4.0/gems/multi_json-1.11.3/lib/multi_json.rb:119:in `load'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-transport-5.0.4/lib/elasticsearch/transport/transport/serializer/multi_json.rb:24:in `load'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-transport-5.0.4/lib/elasticsearch/transport/transport/base.rb:322:in `perform_request'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-transport-5.0.4/lib/elasticsearch/transport/transport/http/faraday.rb:20:in `perform_request'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-transport-5.0.4/lib/elasticsearch/transport/client.rb:131:in `perform_request'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-api-5.0.4/lib/elasticsearch/api/actions/bulk.rb:95:in `bulk'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-model-5.0.1/lib/elasticsearch/model/importing.rb:123:in `block in import'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-model-5.0.1/lib/elasticsearch/model/adapters/active_record.rb:106:in `block in __find_in_batches'
from /app/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.6/lib/active_record/relation/batches.rb:121:in `block in find_in_batches'
from /app/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.6/lib/active_record/relation/batches.rb:214:in `block in in_batches'
from /app/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.6/lib/active_record/relation/batches.rb:198:in `loop'
from /app/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.6/lib/active_record/relation/batches.rb:198:in `in_batches'
from /app/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.6/lib/active_record/relation/batches.rb:120:in `find_in_batches'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-model-5.0.1/lib/elasticsearch/model/adapters/active_record.rb:105:in `__find_in_batches'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-model-5.0.1/lib/elasticsearch/model/importing.rb:122:in `import'
from /app/vendor/bundle/ruby/2.4.0/gems/elasticsearch-model-5.0.1/lib/elasticsearch/model.rb:118:in `import'
from (irb):14
from /app/vendor/bundle/ruby/2.4.0/gems/railties-5.0.6/lib/rails/commands/console.rb:65:in `start'
from /app/vendor/bundle/ruby/2.4.0/gems/railties-5.0.6/lib/rails/commands/console_helper.rb:9:in `start'
from /app/vendor/bundle/ruby/2.4.0/gems/railties-5.0.6/lib/rails/commands/commands_tasks.rb:78:in `console'
from /app/vendor/bundle/ruby/2.4.0/gems/railties-5.0.6/lib/rails/commands/commands_tasks.rb:49:in `run_command!'
from /app/vendor/bundle/ruby/2.4.0/gems/railties-5.0.6/lib/rails/commands.rb:18:in `<top (required)>'
from bin/rails:9:in `require'
from bin/rails:9:in `<main>'
This is proving to be a frustrating issue to debug. I am grateful for any further suggestions or ideas.
Related
I'm getting a PG error and I can't figure out how to rewrite this statement is a way that works. When I run it in the rails console, everything seems to be fine. But when I try to process it as a background job, it borks with the following error:
/Users/lorenzsell/DEV/Heartbeat-pods/app/mailers/notifications_mailer.rb:44:in `community_update'
/Users/lorenzsell/DEV/Heartbeat-pods/app/jobs/send_community_digest_job.rb:17:in `block (2 levels) in perform'
/Users/lorenzsell/DEV/Heartbeat-pods/app/jobs/send_community_digest_job.rb:16:in `block in perform'
/Users/lorenzsell/DEV/Heartbeat-pods/app/jobs/send_community_digest_job.rb:8:in `perform'
/Users/lorenzsell/DEV/Heartbeat-pods/app/jobs/schedule_send_community_digest_job.rb:9:in `block in perform'
/Users/lorenzsell/DEV/Heartbeat-pods/app/jobs/schedule_send_community_digest_job.rb:8:in `each'
/Users/lorenzsell/DEV/Heartbeat-pods/app/jobs/schedule_send_community_digest_job.rb:8:in `perform'
/Users/lorenzsell/DEV/Heartbeat-pods/lib/tasks/email_tasks.rake:10:in `block (2 levels) in <top (required)>'
-e:1:in `<main>'
ActiveRecord::StatementInvalid: PG::FeatureNotSupported: ERROR: FOR UPDATE is not allowed with aggregate functions
: SELECT COUNT(*) FROM "activities" WHERE "activities"."receiver_id" = $1 AND "activities"."is_read" = 'f' FOR UPDATE
/Users/lorenzsell/DEV/Heartbeat-pods/app/mailers/notifications_mailer.rb:44:in `community_update'
Here is the code snippet:
community_ids = Activity.where(receiver_type: "community", is_read: false).uniq.pluck(:receiver_id)
According to the documentation, lock causes ActiveRecord to generate a SELECT ... FOR UPDATE. Postgres won't let you perform a count on such queries (though other databases might--this is probably why it works in the console), so you need to call count on your Activity relation before you call lock.
# base query
notifications = Activity.where(receiver_id: options['id'], is_read: false)
# save count
notifications_count = notifications.count
# apply lock
notifications = notifications.lock(true)
I've got an app with 4 different models which are multisearchable, however they were originally set up with a pg_search_scope; ie:
class Episode < ActiveRecord::Base
include PgSearch
# multisearchable :against => [:title, :description]
pg_search_scope :search_text,
:against => [:title, :description],
:using => {
:tsearch => {:prefix => true}
}
As you can see at one point I tried setting this up the multiserachable way.
Of late there are items we know should be returning that are NOT in the search results, and I thought I'd have to rebuild the pg_search_documents; however that's throwing an error:
irb(main):004:0> PgSearch::Multisearch.rebuild(Show)
PgSearch::Multisearch::ModelNotMultisearchable: PgSearch::Multisearch::ModelNotMultisearchable
from /app/vendor/bundle/ruby/2.0.0/gems/pg_search-0.7.3/lib/pg_search/multisearch/rebuilder.rb:6:in `initialize'
from /app/vendor/bundle/ruby/2.0.0/gems/pg_search-0.7.3/lib/pg_search/multisearch.rb:10:in `new'
from /app/vendor/bundle/ruby/2.0.0/gems/pg_search-0.7.3/lib/pg_search/multisearch.rb:10:in `block in rebuild'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/connection_adapters/abstract/database_statements.rb:202:in `block in transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/connection_adapters/abstract/database_statements.rb:210:in `within_new_transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/connection_adapters/abstract/database_statements.rb:202:in `transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/transactions.rb:209:in `transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/pg_search-0.7.3/lib/pg_search/multisearch.rb:8:in `rebuild'
from (irb):4
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.0.2/lib/rails/commands/console.rb:90:in `start'
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.0.2/lib/rails/commands/console.rb:9:in `start'
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.0.2/lib/rails/commands.rb:62:in `<top (required)>'
from /app/bin/rails:4:in `require'
from /app/bin/rails:4:in `<main>'
irb(main):005:0>
I thought that it might be because of the setup as a pg_search_scope, so I set one class as above with the multisearch:multisearchable :against => [:title, :description] -- but even then I get rebuild problems.
I tried the manual way of deleting from the pg_search table and rebuilding but even THAT's throwing an error:
2.1.0 :010 > Show.find_each{ |record| record.update_pg_search_document }
Show Load (4.8ms) SELECT "shows".* FROM "shows" ORDER BY "shows"."id" ASC LIMIT 1000
NoMethodError: undefined method `update_pg_search_document' for #<Show:0x007fd945a92358>
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activemodel-4.0.2/lib/active_model/attribute_methods.rb:439:in `method_missing'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-4.0.2/lib/active_record/attribute_methods.rb:155:in `method_missing'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/acts_as_follower-0.2.1/lib/acts_as_follower/followable.rb:54:in `method_missing'
from (irb):10:in `block in irb_binding'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-4.0.2/lib/active_record/relation/batches.rb:26:in `block (2 levels) in find_each'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-4.0.2/lib/active_record/relation/batches.rb:26:in `each'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-4.0.2/lib/active_record/relation/batches.rb:26:in `block in find_each'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-4.0.2/lib/active_record/relation/batches.rb:75:in `find_in_batches'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-deprecated_finders-1.0.3/lib/active_record/deprecated_finders/relation.rb:70:in `find_in_batches'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-4.0.2/lib/active_record/relation/batches.rb:25:in `find_each'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/activerecord-4.0.2/lib/active_record/querying.rb:8:in `find_each'
from (irb):10
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/railties-4.0.2/lib/rails/commands/console.rb:90:in `start'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/railties-4.0.2/lib/rails/commands/console.rb:9:in `start'
from /Users/grimm/.rvm/gems/ruby-2.1.0/gems/railties-4.0.2/lib/rails/commands.rb:62:in `<top (required)>'
from bin/rails:4:in `require'
from bin/rails:4
I've been getting the same error while trying to rebuild (for the first time, installing) via the Rails command line with PgSearch::Multisearch.rebuild(Professor). What's worked for me is instead rebuilding from the command line using the alternative approach recommended on the Github:
rake pg_search:multisearch:rebuild[Professor]
This seems to work for me -- it doesn't throw an error, and when I go to the Rails console after and run PgSearch.multisearch("query") it's returning a result, whereas before it was returning an error.
I know this isn't a fix, but it's a solution to the immediate problem. I hope it helps -- posting an issue on their Github might lead to a fuller fix.
I have a rails model that keeps track of other models in an app. (unusual, but necessary for this project).
When I try to assign the attribute model_name I get an error that occurs once, but then doesn't occur again.
AppModel
model_name created_at updated_at
----------------------------------------
User
Question
Post
Answer
In console, I'm getting a strange error:
> model = AppModel.new
> model.model_name = "User" # First time causes the error.
> model.model_name = "User" # Second time it works.
Error:
ActiveRecord::DangerousAttributeError: record_changed? is defined by Active Record
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activerecord-4.1.4/lib/active_record/attribute_methods.rb:104:in `instance_method_already_implemented?'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activemodel-4.1.4/lib/active_model/attribute_methods.rb:288:in `block in define_attribute_method'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activemodel-4.1.4/lib/active_model/attribute_methods.rb:285:in `each'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activemodel-4.1.4/lib/active_model/attribute_methods.rb:285:in `define_attribute_method'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activemodel-4.1.4/lib/active_model/attribute_methods.rb:252:in `block in define_attribute_methods'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activemodel-4.1.4/lib/active_model/attribute_methods.rb:252:in `each'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activemodel-4.1.4/lib/active_model/attribute_methods.rb:252:in `define_attribute_methods'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activerecord-4.1.4/lib/active_record/attribute_methods.rb:75:in `block in define_attribute_methods'
from /Users/donaldpinkus/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/mutex_m.rb:73:in `synchronize'
from /Users/donaldpinkus/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/mutex_m.rb:73:in `mu_synchronize'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activerecord-4.1.4/lib/active_record/attribute_methods.rb:72:in `define_attribute_methods'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activerecord-4.1.4/lib/active_record/attribute_methods.rb:196:in `method_missing'
from (irb):3
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/railties-4.1.4/lib/rails/commands/console.rb:90:in `start'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/railties-4.1.4/lib/rails/commands/console.rb:9:in `start'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/railties-4.1.4/lib/rails/commands/commands_tasks.rb:69:in `console'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/railties-4.1.4/lib/rails/commands/commands_tasks.rb:40:in `run_command!'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/railties-4.1.4/lib/rails/commands.rb:17:in `<top (required)>'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:247:in `require'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:247:in `block in require'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:232:in `load_dependency'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:247:in `require'
from /Users/donaldpinkus/Projects/hooker/bin/rails:8:in `<top (required)>'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:241:in `load'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:241:in `block in load'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:232:in `load_dependency'
from /Users/donaldpinkus/.rvm/gems/ruby-2.1.5/gems/activesupport-4.1.4/lib/active_support/dependencies.rb:241:in `load'
from /Users/donaldpinkus/.rvm/rubies/ruby-2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /Users/donaldpinkus/.rvm/rubies/ruby-2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from -e:1:in `<main>'2.1.5 :004 > e.model_name = "User"
=> "User"
"model_name" isn't a reserved word for models, so what is happening here?
This happens because there is already a method in ActiveRecord models, which is called exactly model_name, that returns (obviously) the name of this model (among other things).
From:
.../ruby-2.1.5/gems/activemodel-4.2.0/lib/active_model/naming.rb
# line 222:
Owner: ActiveModel::Naming
Visibility: public
Signature: model_name()
Number of lines: 12
Returns an ActiveModel::Name object for module. It can be used to
retrieve all kinds of naming-related information (See
ActiveModel::Name for more information).
When ActiveRecord fetches an object from the table, it also creates methods with names corresponding to the column names in the table. What happens is it fetches an object, sees a column model_name on the given object, tries to define a method model_name and suddenly finds out that it already exists.
Here's a thing: avoid needlessly long attribute names. If you're defining a name in a model, it can just be name, it's scoped to "model" class anyway, obviously it's the model's name.
The error reporting code, however, likely contains a bug that needs to be tracked down.
In rails console..
Physician.find(1285849521) results in
ArgumentError: wrong number of arguments (1 for 0)
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `initialize'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `new'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `substitute_at'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:989:in `block in create_binds'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:987:in `each'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:987:in `each_with_index'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:987:in `create_binds'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:962:in `build_where'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:586:in `where!'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:576:in `where'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/querying.rb:10:in `where'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/core.rb:150:in `block (2 levels) in find'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/statement_cache.rb:80:in `call'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/statement_cache.rb:80:in `create'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/core.rb:149:in `block in find'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/2.1.0/mutex_m.rb:73:in `synchronize'
... 13 levels...
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:246:in `load'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:246:in `block in load'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:237:in `load_dependency'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:246:in `load'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/commands/rails.rb:6:in `call'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/command_wrapper.rb:38:in `call'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:180:in `block in serve'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:153:in `fork'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:153:in `serve'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:128:in `block in run'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:122:in `loop'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:122:in `run'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application/boot.rb:18:in `<top (required)>'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
and of course..
Physician.find() results in "ActiveRecord::RecordNotFound: Couldn't find Physician without an ID"
My physician.rb is
class Physician < ActiveRecord::Base
self.table_name = "t_phys"
self.primary_key = "sln"
end
I'm using a legacy postgres db, the table t_phys has a natural key called sln, which is a 10 digit integer. There is a physician in the db with sln 1285849521 (the integer in the find method above), which I know because Physician.all() works properly and that's the first record that is displayed.
What am I doing wrong? How can I get the find method to work properly? I'm just getting started with rails again, probably a newbie mistake somewhere. Appreciate the help!
For more detail, when I got to localhost:3000/physicians/1285849521, the page renders:
ArgumentError in PhysiciansController#show
Wrong number of arguments (1 for 0)
Extracted source (around line #160):
159 def substitute_at(column, index)
160 Arel::Nodes::BindParam.new "$#{index + 1}"
161 end
162
163 def exec_query(sql, name = 'SQL', binds = [])
I can provide the full stack trace if necessary.
Seems like it should work, but I'm wondering if the custom primary key is still messing with find.
Maybe this background will help confirm one way or the other:
http://ruby-journal.com/how-to-override-default-primary-key-id-in-rails/
Thanks to Todd Agulnick's comment above, I updated to Rails 4.2 rc2 and the error went away. I encountered a new error, which I resolved and is outside the scope of this question. Thanks Todd!
I have an error that appears to be connected to these two links:
https://groups.google.com/forum/#!msg/mongoid/L6ESKP8QDpg/gmEyqejdAEEJ
https://github.com/mongoid/moped/pull/59
See console log below. I am running with Mongoid/MongoHQ, when I create an object (apparently any database object) I get this "need to login" error. Note however that the database object IS created and is in the database after the error.
Is there some way I can fix this myself, or perhaps it's something that MongoHQ needs to fix?
$ heroku run console
irb(main):004:0> Request.create!(:from_user => User.first, :to_user => User.first)
Moped::Errors::OperationFailure: The operation: #<Moped::Protocol::Command
#length=69
#request_id=7
#response_to=0
#op_code=2004
#flags=[]
#full_collection_name="admin.$cmd"
#skip=0
#limit=-1
#selector={:getlasterror=>1, :safe=>true}
#fields=nil>
failed with error "need to login"
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:74:in `block in command'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:521:in `[]'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:521:in `block (3 levels) in flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:520:in `map'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:520:in `block (2 levels) in flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:123:in `ensure_connected'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:516:in `block in flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:531:in `logging'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:515:in `flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:286:in `pipeline'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/session/context.rb:58:in `block in insert'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/session/context.rb:109:in `block in with_node'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/cluster.rb:150:in `block in with_primary'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:168:in `ensure_primary'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/cluster.rb:149:in `with_primary'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/session/context.rb:108:in `with_node'
... 13 levels...
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:405:in `__run_callback'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:385:in `_run_save_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:81:in `run_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/callbacks.rb:100:in `run_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence/insertion.rb:23:in `prepare'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence/operations/insert.rb:26:in `persist'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence.rb:50:in `insert'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence.rb:251:in `block in create!'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/threaded/lifecycle.rb:173:in `_creating'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence.rb:249:in `create!'
from (irb):4
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/commands/console.rb:47:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/commands/console.rb:8:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/commands.rb:41:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'irb(main):005:0>
I am having the exact same problem. This is not exactly a solution but you can work around the problem by setting the 'safe' option in mongoid.yml to false. It would look similar to this:
production:
sessions:
default:
uri: <%= ENV['MONGOHQ_URL'] %>
options:
skip_version_check: true
safe: false
It turns out the problem is that MongoHQ upgraded their MongoDB and it introduced an incompatibility with mongoid's stable branch.
Chris Winslett fixed the bug and durran pulled it into mongoid master. But it was not included in the stable branch when I posted this stackoverflow.
Solutions:
I solved the problem by updating my gemfile to pull mongoid from github.
durran has now included it in stable-1.2.0 so you should get the fix if you gem update.