Receive `NoMethodError` when trying to register new tool

[tmciver-mhe]

This issue is seen when clicking the 'Update' button for the tool registration process described in step 11 of the "Getting It Running" section of the README.

I tried to resolve the issue by resetting the databases back to a clean state by issuing the command bundle exec rake db:seed in each application directory. When run in the tp_sample_app directory, it aborted with a messages stating that there was 1 pending migration.

I then ran the command bundle exec rake db:migrate which resulted in the following:

~/workspace/lti/LTI2-Reference/tp_sample_app/db$ bundle exec rake db:migrate
(in /home/tim/workspace/lti/LTI2-Reference/tp_sample_app)
==  CreateLti2TpRegistries: migrating =========================================
-- create_table(:lti2_tp_registrations)
rake aborted!
An error has occurred, this and all later migrations canceled:

SQLite3::SQLException: table "lti2_tp_registrations" already exists: CREATE TABLE "lti2_tp_registrations" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "tenant_key" varchar(255), "tenant_name" varchar(255), "tenant_id" integer, "user_id" varchar(255), "reg_key" varchar(255), "reg_password" varchar(255), "tc_profile_url" varchar(255), "launch_presentation_return_url" varchar(255), "status" varchar(255), "message_type" varchar(255), "tool_consumer_profile_json" text, "tool_profile_json" text, "tool_proxy_json" text, "tool_id" integer, "lti_version" varchar(255), "end_registration_id" varchar(255), "proposed_tool_proxy" text, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL) /var/lib/gems/1.9.1/gems/sqlite3-1.3.8/lib/sqlite3/database.rb:91:in `initialize'
/var/lib/gems/1.9.1/gems/sqlite3-1.3.8/lib/sqlite3/database.rb:91:in `new'
/var/lib/gems/1.9.1/gems/sqlite3-1.3.8/lib/sqlite3/database.rb:91:in `prepare'
/var/lib/gems/1.9.1/gems/sqlite3-1.3.8/lib/sqlite3/database.rb:134:in `execute'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/connection_adapters/sqlite_adapter.rb:278:in `block in execute'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/connection_adapters/abstract_adapter.rb:280:in `block in log'
/var/lib/gems/1.9.1/gems/activesupport-3.2.6/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/connection_adapters/abstract_adapter.rb:275:in `log'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/connection_adapters/sqlite_adapter.rb:278:in `execute'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/connection_adapters/abstract/schema_statements.rb:170:in `create_table'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:466:in `block in method_missing'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:438:in `block in say_with_time'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:438:in `say_with_time'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:458:in `method_missing'
/home/tim/workspace/lti/LTI2-Reference/tp_sample_app/db/migrate/20141020133931_create_lti2_tp_registries.lti2_tp.rb:4:in `change'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:407:in `block (2 levels) in migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:407:in `block in migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/connection_adapters/abstract/connection_pool.rb:123:in `with_connection'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:389:in `migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:528:in `migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:720:in `block (2 levels) in migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:775:in `call'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:775:in `block in ddl_transaction'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/transactions.rb:208:in `transaction'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:775:in `ddl_transaction'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:719:in `block in migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:700:in `each'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:700:in `migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:570:in `up'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/migration.rb:551:in `migrate'
/var/lib/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/railties/databases.rake:153:in `block (2 levels) in <top (required)>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

I then renamed the development.sqlite file and reran the migrate command which seemed to work. Unfortunately, when I tried to register a tool, I saw the following screenshot:

[tmciver-mhe]

The problem seems to be that there is a pending database migration that needs to be applied to the 'Tool Provider' app. Unfortunately, simply attempting to do the migration with bundle exec rake db:migrate results in a Sqlite error that states that the lti2_tp_registrations table already exists. Deleting this table allowed the database migration to proceed without error and the application does not then get the error described above when clicking 'Update' in the during the tool registration process.

Unfortunately, it does receive a '500 Internal Server Error' message on the web page. This seems it may have something to do with updating the lti2_tp_registrations table with the data, but I'm not sure.

[jrissler]

@tmciver-mhe I'll take a look later in the week.

[luis-elumen]

I have the same problem...

[tmciver-mhe]

Has any progress been made towards a solution for this?

[jrissler]

I have not had time to look into this yet.

[rvisintine]

I was able to fix the schema migration by fixing the last migration file. The table and most entries already existed, just the new columns needed to be added.

20141020133931_create_lti2_tp_registries.lti2_tp.rb

# This migration comes from lti2_tp (originally 20131121012233)
class CreateLti2TpRegistries < ActiveRecord::Migration
  def change
    add_column :lti2_tp_registrations, :end_registration_id, :string, :after => :lti_version
    add_column :lti2_tp_registrations, :proposed_tool_proxy, :text, :after => :end_registration_id

  end
end

But now the TC throws a 500 server error

NoMethodError (undefined method `disposition=' for #Lti2Tc::DeploymentRequest:0x007fe63a54beb0):

Will try to dig into it more later.

[jtibbetts]

I've been on medical leave (double knee replacement) since January 27th of this year and just coming back on stream in the last couple of weeks. It looks like there's been activity here during that time.

This repo is supposed to represent LTI2 version 2.0. LTI2.0 was released without support for 'reregistration'; that is, the ability to use the existing LTI trust relationship to renegotiate and update the ToolProxy (including credentials). However in this repo's master branch we picked up some tentative work on LTI2.1 with reregistration support. The 'disposition' parameter was an early approach to signal reregistration. It is no longer used in the 2.1 reregistration support. References to 'disposition' and to reregistration support should be able to be commented out to get this branch working.

Alternatively it looks like the branch labeled LTI2.0 in the LTI-Reference is an earlier version without disposition. This may also satisfy. But I haven't tried it and would have to reinstall some older RoR versions to get it working.

What I would recommend is the following: there is a much reworked version of all this which includes the real (still unreleased) 2.1 code. It also contains a much more elegant structure that James Rissler (jrissler) created based on Rails mountable engines. It is the version we've been using in production for some months now. I'll migrate that over to this public repo in the next week or so. However before I release it to LTI2-Reference I'll want to review it with our team to ensure we're not dragging over some proprietary stuff. So if you can wait for that it might be the best bet.

[rvisintine]

Thanks John, Don't know why I didn't try that before but yeah, the LTI2.0 branch seems to work just fine. Thanks for the response and I hope you're starting to feel better.

[jrissler]

+1 @jtibbetts on moving the new model over instead of repairing this one.