And Then I saw...

[Arlen Walker]

The radiant-dev-box instructions are not correct. I'll add corrections to my github branch of the dev-box as I figure them out. Here's what I've seen so far:

The line about copying the database.yml file seems non-operational. Radiant is controlled by a database.yml located in the spec/dummy/config directory. Ideally the root level config/database.yml should mean something, and eventually it will, but for right now the only one that means anything is located at spec/dummy/config/database.yml

The line with rake db:create:all is non-functional. To create the database, radiant used a db:bootstrap rake task.

I've made changes in the dev box's read me that are in line with these discoveries.

As always, anyone have a better idea on how to deal with anything they find in this thread, speak up. The whole point of putting this thread here is to try and save the next person down this trail from stubbing their toes; if you can make the path smoother than I am, I'm all for it.

[Jim Gay]

It's likely that the bootstrap task should go away, or at least be an alias of db:setup.
The spec/dummy code is a part of the transition to Rails 3+.
Radiant previously could be run as an app itself. I don't see much reason to continue that... in other words, I think it makes sense to treat Radiant as something you add to your Gemfile.
That explains the config/database.yml file in relation to spec/dummy.

[Arlen Walker]

Does look as if db:setup does a portion at least of this. But bootstrap fails at an interesting point ("interesting" as in "WTF is going on with this?") so I'm going to take it apart a bit more so I can understand what's happening and why. (Nutshell version: the Radiant::setup method seems to be executing with a completely different User model than actually exists in the reality of the code. The attributes do not agree with either of the two schemas in the code nor with the actual database table.)

[Arlen Walker]

Does look as if db:setup does a portion at least of this. But bootstrap fails at an interesting point ("interesting" as in "WTF is going on with this?") so I'm going to take it apart a bit more so I can understand what's happening and why. (Nutshell version: the Radiant::setup method seems to be executing with a completely different User model than actually exists in the reality of the code. The attributes do not agree with either of the two schemas in the code nor with the actual database table.)

After some experimentation it appears Radiant::Setup.create_admin_user fails with the version bump of Rails 3.2.8 -- all 3.2.x at or below that point get the correct User attributes, all versions above that get a completely bollixed version of User. I'm tempted to blame it on Sprockets 2.2 (2.1.4 works, 2.2.3 does not) but I'm not chasing that rabbit any farther down this hole. This means the bootstrap code itself is dead with the current radiant.gemspec (s.add_dependency "rails",           ">= 3.2" results in 3.2.20).

Not necessarily a big loss in itself, but it may lead to an explanation of some of the failing tests I'm seeing. And it means that even for Rails 3.2 we're probably better off with db:setup than bootstrap. In fact, since db:setup will also run db:seed, much of what happens in bootstrap might be set to happen there.

On Tuesday, November 11, 2014 12:30:04 PM UTC-6, Jim Gay wrote:

[Jim Gay]

On Nov 12, 2014, at 10:37 , Arlen Walker <arlen....@gmail.com> wrote:

Does look as if db:setup does a portion at least of this. But bootstrap fails at an interesting point ("interesting" as in "WTF is going on with this?") so I'm going to take it apart a bit more so I can understand what's happening and why. (Nutshell version: the Radiant::setup method seems to be executing with a completely different User model than actually exists in the reality of the code. The attributes do not agree with either of the two schemas in the code nor with the actual database table.)

After some experimentation it appears Radiant::Setup.create_admin_user fails with the version bump of Rails 3.2.8 -- all 3.2.x at or below that point get the correct User attributes, all versions above that get a completely bollixed version of User. I'm tempted to blame it on Sprockets 2.2 (2.1.4 works, 2.2.3 does not) but I'm not chasing that rabbit any farther down this hole. This means the bootstrap code itself is dead with the current radiant.gemspec (s.add_dependency "rails",           ">= 3.2" results in 3.2.20).

Not necessarily a big loss in itself, but it may lead to an explanation of some of the failing tests I'm seeing. And it means that even for Rails 3.2 we're probably better off with db:setup than bootstrap. In fact, since db:setup will also run db:seed, much of what happens in bootstrap might be set to happen there.

Yeah. I agree.

We don't need to seed much data at all.

The bootstrap task was in charge of setting the initial user and allowing you to configure the name and password. And it provided hooks to load database templates (certain pages/snippets/layouts already loaded) which this project uses to hook into it https://github.com/radiant/radiant-site_templates-extension

The goal there, being that you can create your own templates and load them if you like.

[Arlen Walker]

At first I thought that "bundle exec rake spec" is broken in master?

The reason I'm asking is that command cannot seem to find the correct database table for FactoryGirl to work with but when I rerun one of the spec files with "bundle exec rspec specfile" it has no trouble finding the correct database table.

With spec:

  28) User roles should not have a non-existent role

     Failure/Error: let(:existing){ FactoryGirl.build(:user) }

     ActiveRecord::StatementInvalid:

       Could not find table 'users'

     # ./spec/models/user_spec.rb:224:in `block (2 levels) in <top (required)>'

     # ./spec/models/user_spec.rb:227:in `block (2 levels) in <top (required)>'

  29) User roles should not have a role for which the corresponding method returns false

     Failure/Error: let(:existing){ FactoryGirl.build(:user) }

     ActiveRecord::StatementInvalid:

       Could not find table 'users'

     # ./spec/models/user_spec.rb:224:in `block (2 levels) in <top (required)>'

     # ./spec/models/user_spec.rb:231:in `block (2 levels) in <top (required)>'

  30) User roles should have a role for which the corresponding method returns true

     Failure/Error: let(:designer){ FactoryGirl.build(:user, designer: true) }

     ActiveRecord::StatementInvalid:

       Could not find table 'users'

     # ./spec/models/user_spec.rb:223:in `block (2 levels) in <top (required)>'

     # ./spec/models/user_spec.rb:236:in `block (2 levels) in <top (required)>'

With spec:

User roles

.  should not have a non-existent role

.  should not have a role for which the corresponding method returns false

.  should have a role for which the corresponding method returns true

30 failures with spec, all pass with rspec.

But then I realized it's the suite that has the issue:

rspec spec/models/*.rb and 5 tests fail

rspec and pretty much all the previously passing tests fail.

[Arlen Walker]

And so far I've found the source of many of the testing issues to be in extension_generators_spec_helper.rb At least, when I remove that file, almost all the failing specs that pass when I use rspec spec/models go back to passing. Specifically it seems to be the patching it does to ActiveRecord -- remove just the AR patches from that file and the 733 test failures drop down to 426 failures. Essentially that section is what causes FactoryGirl to lose her way with all those "cannot find table" errors. I think a better way to test those generators is going to have to be built.

[Arlen Walker]

I'll make it even more specific:

take out the ActiveRecord::Base patch (specifically the attr_accessor line) and the failure count drops from 733 to 487. Remove the ActiveRecord::ConnectionAdapters::Column#initialize patch and it drops from 487 to 426 (most of the failures in that batch are from standard_tags_spec).