I'm trying to build a simple ruby script that connects to a database and runs some basic queries.
The code is here: https://github.com/mastermindg/rack-activrecord-example
It's not a service - only a script that is run manually to do batch jobs. My problem is that I need to populate the database for testing purposes. I know how to do this in Sinatra and Rails but it's failing as-is:
NoMethodError: undefined method `set' for main:Object
Did you mean? send
/usr/src/app/app.rb:7:in `<top (required)>'
/usr/src/app/Rakefile:2:in `<top (required)>'
I've got the database.yml but I can't tell how to load it since set is failing.
How do I connect to and query a database using ActiveRecord with basic Rack?
1) Add this to your Rakefile after the requires:
DatabaseTasks.database_configuration = YAML.load(File.read(File.join(root, 'config/database.yml')))
2) Remove set :database_file, 'config/database.yml' from your app.rb file (I think set is a sinatra/activerecord method).
Running rake db:create may give you an error on your project now,because you're using json instead of JSON in your app.rb file (depending on your local versions), so. . .
3) Change puts json Resource.select('id', 'name').all to puts JSON Resource.select('id', 'name').all in your app.rb file.
Now rake db:create will throw a database error, but that's an error related to your specific database configuration, make an appropriate adjustment to that (this is off-topic from the original question, so I won't address it further) and your app should run as you desire.
More info:
This gist shows example contents of a Rakefile that you could use to run Active Record tasks without using Rails or Sinatra.
I have been struggling for a while with this problem. I'm trying to test a ruby CLI that uses a lot of fileutils operations like making directories and copying files, etc. But when I'm writing tests, I need some way to test the functionality without touching and changing the actual filesystem. I am trying to use the fakefs gem but I am running into a error right away
When I successfully run `dotfiles init` # aruba-0.5.3/lib/aruba/cucumber.rb:71
No such file or directory - No such file or directory - /tmp/aruba-out20130817-15800-ke8nou (Errno::ENOENT)
/Users/Brian/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/tempfile.rb:146:in `open'
/Users/Brian/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/tempfile.rb:146:in `block in initialize'
/Users/Brian/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/tmpdir.rb:142:in `create'
/Users/Brian/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/tempfile.rb:136:in `initialize'
features/dotfiles_repository.feature:8:in `When I successfully run `dotfiles init`'
So its not finding /tmp/aruba which is where cucumber aruba does all of its file operations according to the readme.
The tests run fine without fakefs, so I'm assuming its something with the setup.
Here is my features/support/env.rb file
require 'aruba/cucumber'
require 'fakefs/safe'
Before do
FakeFS.activate!
end
After do
FakeFS::FileSystem.clear
FakeFS.deactivate!
end
Does anyone have any idea what I may be doing wrong? Any help is appreciated. Even if its an idea that doesn't use fakefs, I would like to hear it. Thanks
I'm integrating tests with Rspec into quite a large / developed app. When I run the test I'm getting very odd errors from some of my initializers.
For example, my carrierwave.rb loads a yaml file, when I run the test command I get:
carrierwave.rb:11:in `block in <top (required)>': undefined method `[]' for nil:NilClass
which is referring to the second line of code below:
fog_config = YAML::load_file(Rails.root.join 'config/fog.yml')[Rails.env.to_s]
config.fog_directory = fog_config['directory']
Momentarily if I remove that line of code in carrierwave, omniauth starts to complain too:
omniauth.rb:4:in `block in <top (required)>': undefined method `symbolize_keys' for nil:NilClass (NoMethodError)
Again, another yaml file:
fb_config = YAML::load_file(Rails.root.join 'config/fb_app_version.yml')[Rails.env].symbolize_keys
I'm guessing the solution is to change my yaml files or include something in the tests, but I'm not sure what. Any ideas would be most appreciated, thanks.
It looks like you need to include test entries in the Yaml files in question.
For example, your config/fog.yml probably looks something like this:
production:
directory: the_prod_directory
other_keys: ...
development:
directory: the_dev_directory
other_keys: ...
You need to add a test key:
test:
directory: the_test_dir
other_keys: appropriate values
I'm using RSpec (latest Version, 2.12.2) to test a small Ruby class I'm working on. My problem is that when an RSpec test fails, the test output seems incredibly verbose, and shows a huge list of error messages, almost what seems to be a full backtrace. This means I have to scroll up to see the actual error message and the top of the trace.
I believe by default RSpec is supposed to do this but it doesn't seem to be doing it for me. For example, if I run rspec spec/my_spec.rb:132 (just run one test that's on L132), I get this output:
Failure/Error: #f.has_changed?("test").should be_true
expected: true value
got: false
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/fail_with.rb:33:in `fail_with'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/handler.rb:33:in `handle_matcher'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/syntax.rb:53:in `should'
# /Users/JackFranklin/Dropbox/Sites/rubygems/filefixtures/spec/filefixtures_spec.rb:137:in `block (4 levels) in <top (required)>'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:114:in `instance_eval'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:114:in `block in run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:254:in `with_around_each_hooks'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:111:in `run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:388:in `block in run_examples'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:384:in `map'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:384:in `run_examples'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:369:in `run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `block in run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `map'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `block in run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `map'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:28:in `map'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:28:in `block in run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/reporter.rb:34:in `report'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:25:in `run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/runner.rb:80:in `run'
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/runner.rb:17:in `block in autorun'
Which, as you can see, is absolutely massive. I've not got any RSpec config files around that could be altering the configuration passed to RSpec.
Has anyone seen this before? I've tried Googling but searches have been fruitless.
Edit: I then set up config to make sure it was applying the default backtrace cleaning:
RSpec.configure do |config|
# RSpec automatically cleans stuff out of backtraces;
# sometimes this is annoying when trying to debug something e.g. a gem
config.backtrace_clean_patterns = [
/\/lib\d*\/ruby\//,
/bin\//,
/gems/,
/spec\/spec_helper\.rb/,
/lib\/rspec\/(core|expectations|matchers|mocks)/
]
end
But this doesn't make a difference. Looking at the output, it should be having most of it filtered out but it seems like the configuration isn't being applied?
Edit again:
In my config, I can even run cleaned_from_backtrace?(line) to see if a line should be cleaned. This returns true:
config.cleaned_from_backtrace?("/Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/fail_with.rb:33:in `fail_with'")
But the actual output in the terminal remains the same!
Edit 3:
I am running RSpec with the command rspec, and nothing more. The project's .rspec file contains:
--color
--format progress
And there is no ~/.rspec file either that could be applying settings.
So after a bit more chatting with the RSpec folk on Github, I managed to hunt down the problem.
The problem was that by default, RSpec removes lines from the backtrace that match the Regex /gems/. I had my project within a folder with gems in the name: ~/Dropbox/rubygems/myproject, so every line of the backtrace was being removed, and when that happens, RSpec sensibly shows you the entire backtrace.
That explains the behaviour I was seeing.
It's always something silly like that. I hope if anyone else does this, perhaps this answer will save them some time.
Looks like you're running RSpec with -b, for a full backtrace. Normally, RSpec won't show its own internal backtrace like that, even when your test fails badly (i.e. throws an exception rather than just failing an assertion). If you're not explicitly running it with -b or --backtrace, check and make sure that you don't have that set in a .rspec config file, or that your IDE or whatever isn't passing it.
As Jim said, there's a -b or --backtrace option that will enable the full backtrace. Bear in mind that it's not just the .rspec file that could be triggering it; there's also ~/.rspec (for a developer's preferred options).
The other thing to bear in mind is that a formatter can spit out whatever portion of the backtrace that it wants. The formatters expose a simple way for any 3rd-party formatter to respect the backtrace-filtering configuration, but it you're using a 3rd-party formatter there is no guarantee it is using that properly. Are you using one of the built-in rspec formatters?
Finally, if it's not one of those things, I'm out of ideas. I'd have to have an example to play with to answer your question. Can you come up with a reproducible example (in a gist, hopefully)? I try to hang out in the rspec channel of irc.freenode.net regularly, so maybe you can catch me there and we can do some troubleshooting that way.
From version 3.4.0 / 2015-11-11 it is possible to filter backtrace by option:
RSpec.configure do |config|
config.filter_rails_from_backtrace!
end
I have a Rails 3.1 application running on Heroku Cedar and it has a custom built Admin panel.
Admin is just a namespaced controller/view combination which live in controllers/admin and in views/admin.
I also 'namespaced' the assets: called them assets/javascripts/admin.js.coffe and assets/stylesheets/admin.css.scss and include both from layouts/admin/application.html.haml
Heroku perfectly compiles application.(css.scss|js.coffee) to a javascript/stylesheet files. When I visit frontend application it just works.
But when I visit '/admin' I get the following error:
When I visit website in production I get the following error:
2011-09-19T15:47:18+00:00 app[web.1]: /app/vendor/bundle/ruby/1.9.1/gems/execjs-1.2.5/lib/execjs/runtimes.rb:46:in `autodetect': Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/execjs-1.2.5/lib/execjs.rb:5:in `<module:ExecJS>'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/execjs-1.2.5/lib/execjs.rb:4:in `<top (required)>'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:240:in `require'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:240:in `block in require'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:223:in `block in load_dependency'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:240:in `require'
2011-09-19T15:47:18+00:00 heroku[web.1]: Process exited
2011-09-19T15:47:20+00:00 heroku[web.1]: State changed from starting to crashed
According to Heroku's documentation I don't need to add gems like therubyracer-heroku to my gemfile. My admin asset files are manifest files and are similar to application asset manifests:
# application.js.coffee
#= require jquery
#= require jquery_ujs
# admin.js.coffee
#= require jquery
#= require jquery_ujs
Any thoughts?
Update 19 sept: As it turns out, admin assets are never compiled into public/assets and neither are present in public/assets/manifest.yml
Did you update your application's PATH, as also mentioned in the Heroku documentation you linked?
I had this same problem, adding 'bin' to the PATH solved it.