No route matches controller - scaffold generated code

Since you put --skip-migration, could you post table structure? Maybe
missing an ID or some other field? Reserved word bug? Sometimes I've
had to restart ruby server when working with routes.rb, but shouldn't
be necessary with a fresh scaffold. Problem does seem related to
routes.rb, I bet using:action controller and id in link_to() would work

chris wrote in post #961631:

Here is the table definition from the generated schema.rb

  create_table "dogs", :primary_key => "dog_id", :force => true do |t|
    t.string "color", :limit => 20
    t.string "gender", :limit => 20
    t.string "dog_name", :limit => 20
  end

I used skip-migration because the table already exists in mysql.
When I move from learning mode to development mode, I will need to write
code against existing databases, so I can't maintain the database source
code in ruby.

chris wrote in post #961631:

routes.rb, I bet using:action controller and id in link_to() would work

If you would kindly give me an exact syntax, I'd be like to try it.

I would, however, like to understand why the generated code does not
work.

Bob T. wrote in post #961643:

Here is the table definition from the generated schema.rb

  create_table "dogs", :primary_key => "dog_id", :force => true do |t|
    t.string "color", :limit => 20
    t.string "gender", :limit => 20
    t.string "dog_name", :limit => 20
  end

I used skip-migration because the table already exists in mysql.
When I move from learning mode to development mode, I will need to write
code against existing databases, so I can't maintain the database source
code in ruby.

That's not quite true. You need to learn about rake db:schema:dump.

Anyway, you should be using migrations wherever possible, especially as
you learn.

Best,

Marnen Laibow-Koser wrote in post #961663:

I used skip-migration because the table already exists in mysql.
When I move from learning mode to development mode, I will need to write
code against existing databases, so I can't maintain the database source
code in ruby.

That's not quite true. You need to learn about rake db:schema:dump.

Let me rephrase .. I don't want to depend on ruby for schema
definition, even if it can do it.

Anyway, I did the migrate separately, like this:
  rake db:migrate

It brought all the table definitions over from my mysql database.

That's the problem:

create_table "dogs", :primary_key => "dog_id", :force => true do |t|

I got a similar error under 2.3.8 with your schema. AR expects ID to
be called 'id', you can override it in the model or this would work:

  create_table :dogs' do |t|
    t.string "color", :limit => 20
    t.string "gender", :limit => 20
    t.string "dog_name", :limit => 20
  end

I would also recommend using migrations. Sometimes it feels like
adding a layer of abstraction for it's own sake, but in the long run
it is a great idea.

Did you put
set_primary_key "dog_id"
in the the dog model?

Colin

Bob T. wrote in post #961668:

Marnen Laibow-Koser wrote in post #961663:

I used skip-migration because the table already exists in mysql.
When I move from learning mode to development mode, I will need to write
code against existing databases, so I can't maintain the database source
code in ruby.

That's not quite true. You need to learn about rake db:schema:dump.

Let me rephrase .. I don't want to depend on ruby for schema
definition, even if it can do it.

Why not? IMHO you are making a huge mistake. The advantages of having
Rails manage your DB schema are many -- the app knows what it wants in
the DB; you can have your DB schema in version control with your source
code; changes to the schema are no longer difficult.

Anyway, I did the migrate separately, like this:
  rake db:migrate

It brought all the table definitions over from my mysql database.

How could it do that? rake db:migrate only executes your migration
files.

Best,

# Here is the solution....

class Dog < ActiveRecord::Base
set_primary_key "dog_id"
end

Someone else found this before I saw yours, but that is the problem.
I assumed that scaffold would know what the primary key is , because it
was identified in the migrated schema:

schema.rb

  create_table "dogs", :primary_key => "dog_id", :force => true do |t|
    t.string "color", :limit => 20
    t.string "gender", :limit => 20
    t.string "dog_name", :limit => 20
  end

Thanks for your help!

Colin Law wrote in post #961671:

Regarding migrations -

We use Oracle, MySql , PHP and are just considering using RoR.

If we choose to develop some things in RoR, it will have to learn to get
along with the code and the database tables we already have.

If you use only one technology, I understand why you would recommend
using that technology exclusively. Personally, I don't believe in
getting locked into a particular technology. Thats my choice.

Bob T. wrote in post #961705:

Regarding migrations -

Please quote when replying.

We use Oracle, MySql , PHP, Perl/DBI and are just considering using RoR.

If we choose to develop some things in RoR, it will have to learn to get
along with the code and the database tables we already have.

And so it can. But you should dump the schema into the schema file as I
already suggested.

If you use only one technology, I understand why you would recommend
using that technology exclusively. Personally, I don't believe in
getting locked into a particular technology. Thats my choice.

I don't either. But while you're developing in Rails, you should use
Rails migrations.

It's not great practice to have multiple applications touching the same
DB anyway.

Best,

Dear all,
This is a repost of my question, because the first post is considered as thread
hijack.
I have changed the title, hopefully this time it's not hijacking any threads :smiley:

I have a silly problem in setting up a relationship between 4 models.

I set these 4 models, ComUser, DefJabatan, DefUserRole, DefKelamin. In each
model with name started with 'Def', i put a has_one:ComUser relationship.
So naturally i have 3 belongs_to relationship in ComUser.
I do a simple query in the controller: @users = ComUser.find(:first)
and in the view, i simply put a object debug: <%=debug(@users)%>

and I get this:

--- !ruby/object:ComUser
attributes:
  def_jabatan_id: "1"
  created_at: 2010-11-16 04:31:35
  def_user_role_id: "1"
  gsm: "-"
  updated_at: 2010-11-16 04:31:35
  alamat: "-"
  username: admin
  id: "1"
  def_kelamin_id: "1"
  password: admin
  online_status: "2"
attributes_cache: {}

I'm getting a feeling that I didn't set the relationship right, because i don't
see any attributes addition in the ComUser from the model started with
Def-something that i create above..

Am I missing something here, like violating a naming convention or something?

I even tries to alter the table by implicitly put a foreign key in the table for
ComUser model using sql statements, and the debug result is still the same.
How can i make this relationship work?

Thanks

PS. I put the code snippet that i use for migrating the database and defining
the relationship below.

Regards,
Arga

ComUser < ActiveRecord::Base
   belongs_to :DefKelamin
   belongs_to :DefUserRole
   belongs_to :DefJabatan
Migration:
    create_table :com_users do |t|
    t.timestamps
    t.references :def_jabatan, :null => false
    t.integer :def_kelamin_id, :null => false
    t.references :def_user_role, :null => false
    t.column :username,'varchar(20)', :null => false
    t.column :password,'varchar(20)', :null => false
    end

DefJabatan < ActiveRecord::Base
   has_one:ComUser
Migration:
    create_table :def_jabatans do |t|
    t.timestamps
    t.column :jabatan,'varchar(20)', :null => false
    end

DefUserRole < ActiveRecord::Base
   has_one:ComUser
Migration:
    create_table :def_user_roles do |t|
    t.timestamps
    t.column :role,'varchar(20)', :null => false
    t.string :description, :null => false
    t.string :icon
    end

DefKelamin < ActiveRecord::Base
    has_one :ComUser
Migration:
    create_table :def_kelamins do |t|
    t.timestamps
    t.column :kelamin,'varchar(10)', :null => false
    end

arga aridarma wrote in post #961713:

Dear all,
This is a repost of my question, because the first post is considered as
thread
hijack.
I have changed the title, hopefully this time it's not hijacking any
threads :smiley:

Still hijacking. Please start a new thread.

Best,

arga aridarma wrote in post #961713:

Dear all,
This is a repost of my question, because the first post is considered as
thread
hijack.
I have changed the title, hopefully this time it's not hijacking any
threads :smiley:

Still hijacking. Please start a new thread.

What are you talking about? I'm reading this via the mailing list; on
this end of things _both_ of arga's mails are hijacking nothing.

If you check via Google Groups, it did.

> arga aridarma wrote in post #961713:
>> Dear all,
>> This is a repost of my question, because the first post is considered
>> as
>> thread
>> hijack.
>> I have changed the title, hopefully this time it's not hijacking any
>> threads :smiley:
>
> Still hijacking. Please start a new thread.

What are you talking about? I'm reading this via the mailing list; on
this end of things _both_ of arga's mails are hijacking nothing.

If you check via Google Groups, it did.

Huh.

Link to the original thread, which was originally titled “No route matches controller - scaffold generated code”

http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ff7ff1c1dd447e90

> If you check via Google Groups, it did.

Huh.

Link to the original thread, which was originally titled "No route matches
controller - scaffold generated code"
http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ff7ff1c1dd447e90

Clearly Google Groups does more leg-work compared to Gmail in keeping
threads together. I was rather as confused as arga. Sorry, all.