Getting started

[Arlen Walker]

So, I tweaked the Vagrant dev-box to get to a more recent ruby (Since Rails 5, due in 2015, will require ruby 2.2, seems a good idea to get somewhere near there on the march toward Rails 4). The tweaks can be seen in the paladin branch at: https://github.com/Paladin/radiant-dev-box/tree/paladin (in a nutshell, a switched the port from 3000 to 3333 because my system has something occupying 3000 -- personal tweak, AFAICT not necessary for everyone -- then added in a repo that held current rubies.)

That got me to the point where I could attempt the bundle install. I got a dependency conflict on tzinfo, so I moved the minimum in radiant.gemspec up to 0.3.29. like ActiveRecord for Rails 3.2 (the Rails version in the master branch) required so it would get past that and show what else had issues. The only other thing I ran into is the debugger gem is lagging a bit, so in order to finish the install I switched the line in the gem file from pry-debugger to pry-byebug.

Root cause of that was simply that debugger requires a separate set of files for every incremental version of ruby, and my dev-box was on 2.1.3 while Debugger only had files to support 2.1.1. Alternative solutions, if you wish, are to back the ruby version down to 2.1.1 or earlier or to test the 2.1.1 files in debugger against 2.1.3 (a quick scan of the change logs didn't turn up an obvious reason they wouldn't work, but that could be deluded) and then rebuild the debugger gem. Or drop the debugger completely. Have to admit, personally, I rarely fire up the debugger; I think maybe twice in the last two years. But again, that's personal taste rather than anything else, so feel free to solve those issues in any of the alternative ways; they all should work equally well. That leaves us with several hundred failing tests and the question if we want to keep the master headed towards Rails 3.2, or swap in Rails 4 now, when so much is broken anyway, and skip 3.2 completely.

But I'm getting puzzled:

bundle exec rake db:create:all isn't doing what I expect, because despite copying the sqlite database config yaml into database.yml it not only fails to create any databases, it fails to yield an error message, so the failure cause is unknown.

This results in a lot of error messages during the tests saying (for example):

  5) Radiant::Admin::ExtensionsController GET to /admin/extensions should pre-set the template name

     Failure/Error: login_as :admin

     ActiveRecord::StatementInvalid:

       Could not find table 'users'

Anyway, that's where I am in getting this set up. If I could figure past the table not found errors I'd be a lot happier about trying to fix other failing tests. But the table not found errors make me wonder if the config isn't right, yet, so all the other results I get could be false as well.

[Jim Gay]

I'm not sure what's going on there. I haven't used the dev box repository yet but I'll try to set it up today.

I've sent you an invitation to the repository for it.

I went to bundle the master branch and realized that I had too new of a version of Ruby for it. 

I've been keeping Ruby 1.9.x around merely for getting things going in Radiant. I find this frustrating.

I'm ok with pushing forward to Rails 4 on master.

Thanks so much for trying it out and sending feedback.

-Jim

[Arlen Walker]

OK, this is a little stranger:

db:setup works as well to create the db's but:

rake app:db:bootstrap also creates a new user but the user model it seems to be pulling from is not the one I'd expect. Not sure what's happening, but User.new builds a record with developer as an attribute, but the column in the was renamed in a previous migration to designer, so it can't save. I don't find anything explicitly creating the developer column, so it's almost like it's hanging around from a previous migration. Saving the record of course fails because the column doesn't exist, but I haven't seen yet what's creating that attribute in the first place.

I can stop the code and drop into pry during the create_admin_user method and while the users table is expecting the designer column, User.new creates a record with the developer column and no designer column even though it claims it's pointed at the same table. And it's not a bug in sqlite (hey, never trust anything) because the same thing happens with postgresql. In fact, the User record created by User.new seems to be missing anything in a migration done after 019 (no session or language/locale columns either).

It's tempting to just delete all the migrations and see what happens, but that's not getting at the cause of the issue. IIRC, db:setup simply wipes the db and sends the current schema.rb in as the database setup. without doing the migrations.

This is flaky enough to make me wonder it's something local to my system or the VM. So I tried it on my local system out of the vm (rails 4 and ruby 2.0) and it worked. So maybe I should go back a rebuild the VM in a few other variations, just to pin this down. I'd rather know if this is a ruby 2.1 or Rails 4 issue before I start tearing my hair out over it.

[Jim Gay]

On Nov 11, 2014, at 18:01 , Arlen Walker <arlen....@gmail.com> wrote:

OK, this is a little stranger:

db:setup works as well to create the db's but:

rake app:db:bootstrap also creates a new user but the user model it seems to be pulling from is not the one I'd expect. Not sure what's happening, but User.new builds a record with developer as an attribute, but the column in the was renamed in a previous migration to designer, so it can't save. I don't find anything explicitly creating the developer column, so it's almost like it's hanging around from a previous migration. Saving the record of course fails because the column doesn't exist, but I haven't seen yet what's creating that attribute in the first place.

I can stop the code and drop into pry during the create_admin_user method and while the users table is expecting the designer column, User.new creates a record with the developer column and no designer column even though it claims it's pointed at the same table. And it's not a bug in sqlite (hey, never trust anything) because the same thing happens with postgresql. In fact, the User record created by User.new seems to be missing anything in a migration done after 019 (no session or language/locale columns either).

db:setup is unlikely to give you a workable database. I don't think anyone has addressed moving the boostrap stuff in there (that I recall).

At a certain release the developer role was renamed to designer https://github.com/radiant/radiant/blob/master/db/migrate/20090929164633_rename_developer_role_to_designer.rb

It's surprising that the schema would load the developer column... Perhaps it rain the migrations and failed to continue past the renaming of the column..?

[Arlen Walker]

On Nov 12, 2014, at 9:42 AM, Jim Gay <j...@saturnflyer.com> wrote:

It's surprising that the schema would load the developer column... Perhaps it rain the migrations and failed to continue past the renaming of the column..?

But IIRC db:setup doesn’t do migrations, it just loads schema.rb and goes.

[Jim Gay]

Actually, you're correct.

And that's probably not a viable option for the future.

If you add radiant to your rails project, you'll need to run the migrations anyway. We should probably consolidate them for that, but that's beside the point.

There's a relevant post from Pivotal Labs about keeping things the way Radiant has always worked with extension migrations http://pivotallabs.com/leave-your-migrations-in-your-rails-engines/

The issue we'll need to decide is whether or not Radiant will namespace the tables it uses, or assume that it will own them.

I think owning the tables is probably fine, with the exception of users. We should move forward expecting that a project will bring it's own users.

As far as getting it running on a newer version of rails, I think we could ignore the fact that Radiant owns all the tables (including users) for now.