Trying to annotate in rails project results in error

[TomSchillemans]

When I try to annotate schema.rb file generated by rails it gives me this error

# ~> NameError: uninitialized constant ActiveRecord

I have no idea if it has to do with rails or not. I get an uninitialised constant error on controllers as well.
I use Atom. my SiB version I got installed is 2.2.0

[JoshCheek]

The issue

When you run SiB against a file, it only runs that one file. So it's like running ruby db/schema.rb, which also can't know about the environment that the schema was expecting to run in. You can see will do the same thing:

$ ruby db/schema.rb
db/schema.rb:14:in `<main>': uninitialized constant ActiveRecord (NameError)

Quick feedback for ActiveRecord

Atom's SiB ships with a few snippets for common environmental things. One of them is to allow you to play with ActiveRecord::Base:

Snippet to play with ActiveRecrd

• Set filetype to Ruby
• Type s_arb (stands for "snippet: ActiveRecord::Base`)
• Press tab

This will expand you out a snippet that sets up a sample schema and models. At the bottom, you can write whatever code you'd like, e.g. whatever you're thinking about putting in a controller or a test or whatever.

It runs against an in-memory ActiveRecord so that you can run it and tweak it as many times as you'd like without the runs affecting each other.

The effectiveness increases proportional to your ability to extract out the idea you are trying to play with. E.g. you don't need it to look like your real environment, if you can recognize that the question you're trying to answer is "how do I query a has_many where the table name differs from the model name?", then you can edit it to that context in under a minute, and start figuring out the answer.

Running against the real schema

Personally, I just copy/paste/edit the real schema over the top of the snippet's schema, I find this very effective (quick to do, and lets me explore the idea without all the context/complexity/cost of the app).

But, if you really do need it to look like your real environment (I'm highly skeptical), then you could swap the bit of code dealing with the schema with a bit that loads your real schema:

# I deleted the logging code, b/c it was verbose and I didn't need logging for this example
require 'active_record'  # => true
ActiveRecord::Base.establish_connection adapter: 'sqlite3', database: ':memory:'  # > ...
require '/Users/josh/code/turingschool/apply/db/schema'  # => true

class Application < ActiveRecord::Base  # => ActiveRecord::Base
end                                     # => nil

Application.column_names  # => ["id", "user_id", ...

# >> -- create_table("applications", {:force=>true})
# >>    -> 0.0063s
# >> -- add_index("applications", ["user_id"], {:name=>"index_applications_on_user_id"})
# >>    -> 0.0157s
# ...

Completely against the real env

In general, the more real you need it to be, the more you will swap its generic pieces with pieces that come from your app. For example, to make it actually run against your actual app (note that this will be expensive, b/c you have to pay the cost of loading the entire Rails world every time -- you may have to edit settings to extend the timeout), then you can load config/environment.rb like this:

# Apparently we have relative requires in our app, so have to run it from the app root
Dir.chdir '/Users/josh/code/turingschool/apply'

# Load the Rails app
require './config/environment' # => true

# I've got three applications in my dev database
Application.count  # => 3

You can do whatever else you need before loading it, e.g. I've done things like ENV['RAILS_ENV'] = "production" and run it against your prod db (we had a read-only user, don't do this if you could accidentally fuck the prod data).

Controllers

I haven't explored how to get controllers to work. At the end of the day, I know it's "load some set of files, give it a hash that looks like a rack env". I figured out how to do it for Sinatra (snippet s_sinatra) but haven't explored how to get Rails to do it. You can probably get it with that last snippet since it loads the whole world, and then take the hash from the Sinatra snippet. It doesn't sound very convenient, though, Controllers have massive dependencies, which makes them a total PITA to work with (this is why, for example, your business logic should move to a service object as it gets more complex, you don't want it coupled to web requests and haml templates).

Personally, I'd probably just drop a pry into the controller, but if you can find a way to get quick effective feedback, let me know and I'll incorporate it into the snippets.

[JoshCheek]

Oh, also, SiB 3 beta is more stable than 2.2.0, it doesn't install by default b/c it's beta:

$ gem install seeing_is_believing -v 3.0.0.beta.6

Maybe I should just fucking release it, but I'm hoping to get editor integration set up nice before I do, b/c right now, installing is a total PITA and probably cripples adoption.