Rails - Jul 2006 - Need Help Understanding Situation with Table Columns

I am trying to create an application loosely based on the Depot application
presented in Agile Web Development with Rails (AWDwR).  I am using InstantRails
for the server.  In my app I have the folowing controllers:

admin_controller  
application_controller
city_map_controller (with method: displayGMap)


The admin_controller was created with the following command:

ruby script/generate scaffold Gmap Admin

so that I could easily create records in the gmaps table (created with this
code):

DROP TABLE IF EXISTS `gmaps`;
CREATE TABLE `gmaps` (
  `id` int(11) NOT NULL auto_increment,
  `type` tinyint(4) NOT NULL default ''0'',
  `description` varchar(100) collate latin1_general_cs NOT NULL default
'''',
  `lat` float NOT NULL default ''0'',
  `lon` float NOT NULL default ''0'',
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_cs 
  COMMENT=''For storing certain geolocations'' AUTO_INCREMENT=6
;


In the Gmap model I have the following code:

class Gmap < ActiveRecord::Base
require ''pp''
validates_presence_of(:type)
validates_inclusion_of(:type,
    :in => 0..4,
    :message => "should be a valid abcRealty Map type")

def self.allMapPoints
#  Gmap.find(:all,
#    :order => "description asc")
results = find_by_sql("select id, description from gmaps WHERE 1")
pp results[0]
pp(Gmap.columns_hash[''type''])
results
    end

Note that I cannot get the ''find :all'' statement to work.  It
yields a failure:

 SyntaxError in City mapController#index
 (eval):1:in `compute_type'': compile error
 (eval):1: parse error, unexpected tINTEGER
 Object::0
          ^
 C:/INSTAN~1/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/base.rb:1244:in
`compute_type''

If I switch to my debug statements, when I do reference the
''type'' field
in the ''find_by_sql'' statement I get an identical error.

If I don''t reference the ''type'' field in the
''find_by_sql'' statement I get
the following on the application console (running WEBrick):

=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
#<Gmap:0x38b31a8 @attributes={"id"=>"1",
"description"=>"City: Palo Alto, CA"}>
#<ActiveRecord::ConnectionAdapters::MysqlColumn:0x38bee60
 @default=0,
 @limit=4,
 @name="type",
 @null=false,
 @number=true,
 @primary=false,
 @sql_type="tinyint(4)",
 @text=false,
 @type=:integer>
 
 
 At first I thought I had corrupted something when I added the
''type'' column to
 the gmaps table using phpMyAdmin. (I also reran the scaffold generator to
update that;
 recall my app is like the Depot app in AWDwR.) The only thing I have found so
far
 to get this working is to rename the ''type'' column to
something else.
 Then everything works fine.  My question is this: why do I get this behavior
when
 I name a table column ''type''?  I am a newcomer to Ruby and
Rails.  Is there
 something I am missing?

On 7/8/06, johnmann@mannandassociatescpa.com
<johnmann@mannandassociatescpa.com> wrote:
> Note that I cannot get the ''find :all'' statement to work.
It yields a failure:
>
>  SyntaxError in City mapController#index
>  (eval):1:in `compute_type'': compile error
>  (eval):1: parse error, unexpected tINTEGER
>  Object::0
>           ^
There are two reasons for the type column being problematic:
Object.type is a deprecated alias for Object.class and because of
Single Table Inheretence where the type column is supposed to be the
class of an object. STI is used when you want to have a staff table
but to have Manager, Employee, etc. objects that all share mostly the
same attributes.

But it sounds like you found the solution, rename the column and it
may fix everything. My thinking is that it''s trying to load an object
called 0 (or 1,2,3, or 4) because that''s what''s in your type
column.
But it''s blowing its lid when it can''t find a model called 0.
Thus the
ugly error about compute_type, it can''t figure out which type to make
the object it''s returning.

Hope that helps a little bit,
Chuck Vose