 |
Forums |
Admin  Start New Thread
By: Alex Pitigoi
 RE: AWDWR2 ibm_db sessions migration fails [ reply ]
2007-11-29 15:58
|
There is at least one ConnectionAdapter method that needs to be overridden to comply with DB2 syntax:
def remove_index(table_name, options = {})
execute("DROP INDEX #{index_name(table_name, options)}")
end
That would eliminate the "on <table_name>" addition that doesn't work on DB2.
We are in the process of running the entire Rails test suite on all platforms (LUW, i5, z/OS, Informix IDS) to see if anything else needs to be considered. We'll keep you posted on the progress.
|
By: Joshua Poulson
RE: AWDWR2 ibm_db sessions migration fails [ reply ]
2007-11-29 15:29
|
I rolled back my migration, made the changes you suggest, and ran it again with the originally generated migration with no issues.
Will ibm_db stop overloading ConnectionAdapter methods in the future or will I need to keep making this change in future revisions?
|
By: Joshua Poulson
RE: AWDWR2 ibm_db sessions migration fails [ reply ]
2007-11-29 14:50
|
Thanks for your help. I changed 004_add_sessions.rb to include a name for the indexes:
<pre>class AddSessions < ActiveRecord::Migration
def self.up
create_table :sessions do |t|
t.column :session_id, :string
t.column :data, :text
t.column :updated_at, :datetime
end
add_index :sessions, :session_id, :name => "ROR_SNOISSES_IDX_ID"
add_index :sessions, :updated_at, :name => "ROR_SNOISSES_IDX_UP"
end
def self.down
drop_table :sessions
end
end</pre>
|
By: Alex Pitigoi
RE: AWDWR2 ibm_db sessions migration fails [ reply ]
2007-11-29 14:36
|
Hi Joshua,
It seems to me there are a couple of issues at play here, that explain the behavior:
1. Although, the AWDwR code in subsequent chapters only shows migration 004 creating 1 index (add_index :sessions, :session_id), somehow the db:sessions:create does indeed create a 2nd index for :updated_at which happens to be baptized by the IBM_DB adapter with the same name. While this 2nd index might be expected while using Rails-1.2.5 and above, it seems to also hit an old adapter limit with regards to index add/remove, and for that you should open a ticket. I shall describe below the details and provide a quick work-around.
2. As you are probably aware, Rails' Migration is yet to support transactions (http://dev.rubyonrails.org/ticket/5470), and that causes troubles when moving versions up and down after a unit of work failed (adding 2nd index with an identical generated name). That being said, depending on your current version level (stored in SCHEMA_INFO tables) you would need to repair the schema inconsistencies by dropping the sessions table in order to rerun migration 004.
Now, with regards to add/remove index in the IBM_DB adapter, it currently overrides quite badly the following ConnectionAdapter methods:
def add_index(table_name, column_name, options = {})
def remove_index(table_name, options = {})
def index_name(table_name, options)
All that was trying to work around an index name length limitation (18 chars) on some platforms. While this limitation is now lifted, the code that generates and limits the index name could be safely removed, allowing free creation of index names based on fully qualified names. Just plainly remove all 3 methods above (yeap, I tried, it works on LUW :) from gems\ibm_db-0.9.1-mswin32\lib\active_record\connection_adapters\ibm_db_adapter.rb (lines 912-982) until we provide and test the fix on all supported platforms (including i5, z/OS, IDS).
Please let me know if you still encounter issues. Thanks.
|
By: Joshua Poulson
AWDWR2 ibm_db sessions migration fails [ reply ]
2007-11-28 23:48
|
Trekking along fine through "Agile Web Development With Rails" 2nd Ed with 0.9.1 ibm_db, rails 1.2.6 and ruby 1.8.6 [i386-mswin32] connected to DB2 v9.5 ESE... until I get to page 97 of the book, where we put sessions support into our demonstration rails application:
> rake db:sessions:create
exists db/migrate
create db/migrate/004_add_sessions.rb
> rake db:migrate --trace
(in C:/Rails/depot)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
== AddSessions: migrating =====================================================
-- create_table(:sessions)
rake aborted!
ActiveRecord::StatementInvalid: [IBM][CLI Driver][DB2/NT] SQL0601N The name of the object to be created is identical to the existing name "JRP.SESSIONS" of typ SQLCODE=-601: CREATE TABLE sessions (id INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 100) PRIMARY KEY, session_id varchar(255) DEFAULT NULL, data clob
DEFAULT NULL, updated_at timestamp DEFAULT NULL)
...
Looking into db/migrate/004_add_sessions.db we see:
class AddSessions < ActiveRecord::Migration
def self.up
create_table :sessions do |t|
t.column :session_id, :string
t.column :data, :text
t.column :updated_at, :datetime
end
add_index :sessions, :session_id
add_index :sessions, :updated_at
end
def self.down
drop_table :sessions
end
end
Rolling back drops the sessions table, rolling forward gets the same error. I'd like to move forward in this chapter, is it a ibm_db problem, a rails problem, or a silly me problem? I'd hate to think the rails people didn't know that "sessions" was a DB2 reserved word (although I thought DB2 v9 .5 had no reserved words, per https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.sql.ref.doc/doc/r0001095.html ).
Thanks for your help. --jrp
|
|
|
