inconsistent data in mySQL using string field

rubyonrails-talk
#1

I have a migration:

class CreateCodeRequests < ActiveRecord::Migration
  def self.up
    create_table :code_requests do |t|
      t.string :key_number
      t.string :version
      t.datetime :maint_end_date
      t.string :nls_name
      t.string :company_name
      t.string :email_address
      t.boolean :temp
      t.integer :temp_week_to_start
      t.integer :temp_num_weeks

      t.timestamps
    end
  end

  def self.down
    drop_table :code_requests
  end
end

and two fixtures in a .yml file:

one:
  id: 1
  key_number: 0200699
  version: 12.2
  maint_end_date: 2009-05-31 12:00:0
  nls_name: automod
  company_name: U of Anywyere
  email_address: Joe.Smith@uanywhere.edu
  temp: false
  temp_week_to_start:
  temp_num_weeks:

two:
  id: 2
  key_number: 0200100
  version: 12.2
  maint_end_date: 2009-03-27 12:00:00
  nls_name:
  company_name: Company1
  email_address: sue_jones@company1.com
  temp: false
  temp_week_to_start:
  temp_num_weeks:

When I do the migration and load the fixtures I get data in the
key_number field of 0200699 for the first one, but 65600 for the 2nd
one, unless I put quotes around "0200100". What could be the reason for
this?

TIA!

LG Rains

#2

When I do the migration and load the fixtures I get data in the
key_number field of 0200699 for the first one, but 65600 for the 2nd
one, unless I put quotes around "0200100". What could be the reason
for
this?

because yml assumes that it's a number in base 8. with the quotes it
sees that it's a string and doesn't do anything with it.

Fred

#3

Frederick Cheung wrote:

When I do the migration and load the fixtures I get data in the
key_number field of 0200699 for the first one, but 65600 for the 2nd
one, unless I put quotes around "0200100". What could be the reason
for
this?

because yml assumes that it's a number in base 8. with the quotes it
sees that it's a string and doesn't do anything with it.

Fred

Good answer, I knew that :slight_smile: Except, 0200699 has the leading 0 on it.
Is it the fact that 0200699 has 9 in it - a non-base 8 digit?

I'd guess so.

Fred