[typo] more migration problems

Piers Cawley pdcawley at bofh.org.uk
Mon Mar 27 10:39:18 EST 2006

Matt Rose <mattrose at folkwolf.net> writes:

> 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 :)

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.

Piers Cawley <pdcawley at bofh.org.uk>

More information about the Typo-list mailing list