Matt Rose <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.bofh.org.uk/ _______________________________________________ Typo-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/typo-list
