I tried upgrading my dev environment to 946 from 876 and I get this
error when I fire up r946
ActiveRecord::StatementInvalid in Articles#index
Mysql::Error: Table ‘typo_dev.blogs’ doesn’t exist: SELECT * FROM
blogs LIMIT 1
So I thought, “OK, I’ll migrate my db by hand”
So I go into my rails dir, and I type rake migrate, and I get this.
mattrose@venice:~/rails/typo$ rake migrate
(in /home/mattrose/rails/typo)
rake aborted!
Mysql::Error: Table ‘typo_dev.blogs’ doesn’t exist: ALTER TABLE blogs
ADD settings text
(See full trace by running task with --trace)
I ran the trace, but it just gave me the same glaring error.
My r876 rev didn’t have the blogs table.
am I missing a step here, or should the migration include a step that
creates that blogs table.
Matt
PS: off to search the list archives.
Matt R. [email protected] writes:
So I go into my rails dir, and I type rake migrate, and I get this.
My r876 rev didn’t have the blogs table.
am I missing a step here, or should the migration include a step that
creates that blogs table.
It does. In migration 38.
You’ve not rolled your own migration 38 have you?
On Mon, 27 Mar 2006, Piers C. wrote:
It does. In migration 38.
You’ve not rolled your own migration 38 have you?
DOH! I knew that would get me in trouble. See my other post for why.
I
rolled my own db migration to get the feed_tools cache in. It happened
to
be migration 38.
Thanks for your help.
You wouldn’t happen to know the best way for sidebar plugins to alter
the
database structure? My way is obviously sub-optimal 
–
Matt R. [email protected] Visit my blog!
He’s a benighted neurotic gangster plagued by the memory of his family’s
brutal murder. She’s a manipulative antique-collecting bounty hunter
operating on the wrong side of the law. They fight crime!
Matt R. [email protected] writes:
be migration 38.
Thanks for your help.
You wouldn’t happen to know the best way for sidebar plugins to
alter the database structure? My way is obviously sub-optimal
Depends what you need to stash, and how searchable it should be.
Assuming the sidebar’s adding its own table (as opposed to adding
something to an existing table; not something I’d recommend), the best
idea seems to be to have its configuration method check that the table
exists to create it if necessary; if it can’t create the table, it can
then throw an error at configuration time, thus preventing the sight
of 500 errors on the main page.
In general, unless a sidebar’s in core, it shoudln’t use a migration,
and it shouldn’t alter the structure of any of the ‘core’ tables. You
are free to use Content.whiteboard any way you see fit (but be careful
choosing your key names), and you can add settings to Blog.settings
(it’s another serialized hash). You should even be able to call
‘Blog.setting …’ in your controller file and create methods on the
blog object, but be a bit careful with that – I can’t guarantee it’ll
always work.