Well, it would be nice to do in one step what I thought required four! So
let me try...
1. Add another attribute *toys.size* to the schema (this looks different
from the previous step 1 only because I have replaced my SQLite DB with a
PostgreSQL one, named *sunward_x*:
[sunward@web324 x]$ rails dbconsole
...
psql (9.1.15)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
sunward_x=> \d toys
Table "public.toys"
Column | Type | Modifiers
--------+-------------------+-----------------------------------------------
id | bigint | not null default nextval('toy_seq'::regclass)
name | character varying |
color | character varying |
price | money |
sunward_x=> ALTER TABLE toys ADD size INTEGER;
ALTER TABLE
sunward_x=> \d toys
Table "public.toys"
Column | Type | Modifiers
--------+-------------------+-----------------------------------------------
id | bigint | not null default nextval('toy_seq'::regclass)
name | character varying |
color | character varying |
price | money |
size | integer |
If step 1 is all that's needed, I should be able to bring up any *toys *page
an see the new *size *column, right? But I don't:
As far as I can tell, at this point the app does indeed seem to be
oblivious to the change in the DB schema. If so, certainly *something *more
needs to be done to update the app.
Perhaps I can go right ahead to my old step 4, which is to run *scaffold,
*without
updating schema.rb (old step 2) or running *schema_to_scaffold* (old step
3). Perhaps, as you say, "Rails WILL READ THE SCHEMA FROM THE DATABASE"
and gen everything up if I just do this.
[sunward@web324 x]$ rails generate scaffold Toy --no-migration
Well, no. What it has done is to gen up a *Toys *model (and supporting
views) with no columns at all:
Maybe step 2 is necessary to do before step 4, still skipping step 3?
[sunward@web324 x]$ rake db:schema:dump
[sunward@web324 x]$ rails generate scaffold Toy --no-migration
That does, of course, add the new column to *schema.rb.* But the *scaffold
*generator still puts out model objects that are devoid of columns; the *toys
*web page looks just like it did before.
Of course, I can omit step 3, because all *schema_to_scaffold *does is
"READ THE SCHEMA FROM THE DATABASE" and put out a suitable command for
invoking *scaffold. *But without it, I have to read the database schema
myself and manually type the list of columns into the *scaffold* command.
Not sure what's easier about that.
So, if there really is a simpler process for doing this, I guess I need you
to spell it out for me.
Hmm... Maybe this statement from you is a clue to where we have
miscommunicated: "You can manage your database schema using Rails &
migrations, or you can manage it completely outside of Rails. Either option
is pretty easy, while a mishmash combination of the two is not so easy."
This whole thread is not about *"managing my database schema"* - as stated
in the original post, I intend to create and make all changes to my DB
schema entirely outside of Rails. Given that intention, this post is about
*managing
the Rails objects that work with the database schema*, and using Rails
generators and other tools to automate that process as much as is
possible. If you have any ideas for how to do that faster/better/easier
than the procedures that I have cobbled together so far thru
trial-and-error and the hints provided in this thread, I would be grateful
to hear them.
~ Tx, Ken
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/4700e5a7-a56d-4390-91fe-63e821f6c607%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
