Forum: Typo more migration problems

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
44d5033f854ba9246875c840f88ef0d3?d=identicon&s=25 Matt Rose (Guest)
on 2006-03-25 17:37
(Received via mailing list)
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.
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-03-27 16:20
(Received via mailing list)
Matt Rose <mattrose@folkwolf.net> 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?
44d5033f854ba9246875c840f88ef0d3?d=identicon&s=25 Matt Rose (Guest)
on 2006-03-27 17:02
(Received via mailing list)
On Mon, 27 Mar 2006, Piers Cawley 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 Rose     mattrose@folkwolf.net    Visit my blog!
http://folkwolf.net
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!
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-03-27 17:41
(Received via mailing list)
Matt Rose <mattrose@folkwolf.net> 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.
This topic is locked and can not be replied to.