function get_forums causes excessive db queries

[_ck_]

I hope the new get_forums was written this way just to get it into place and will be optimized at some point? If a site has a couple dozen forums, it causes a couple dozen queries, ironically most will be empty returns if there is no meta used:

foreach ( $_forums = (array) $bbdb->get_results("SELECT * FROM $bbdb->forums $where ORDER BY forum_order") as $f ) {
in the loop?! -->>  $f = bb_append_meta( $f, 'forum' );  <<--
 	            $forums[(int) $f->forum_id] = $f;
 	            $forum_ids[] = (int) $f->forum_id;
 	            wp_cache_add( $f->forum_id, $f, 'bb_forum' );
 	            wp_cache_add( $f->forum_slug, $f->forum_id, 'bb_forum_slug' );
 	        }

This should be done like the topic meta where it's all appended with a single db query that is built from the id #s, then post-processed.

I also concerned that the pre-load all options switch is now broken/ignored and each option is loaded individually on demand. But I am going to assume it's just something that has not been addressed yet due to limited time.

bb_meta is a decent concept but please remember that mysql can only use one index for any query making bb_meta always slow since it will require full scans after the meta type is specified (that's your one index). Joins on the data may not even be able to take advantage of the indexes, unlike topicmeta or usermeta which can use it's one index to join on the ID # (bb_meta will need two pieces of info, the ID # AND the meta type, but only one index can be used).

MySQL can only use one index at a time, but that index may span multiple columns.

KEY `object_type__object_id__meta_key` (`object_type`, `object_id`, `meta_key`)

that index means we'll never do a full table scan if we look at, say, forum meta for forum_id = 1.

(In [1644]) lookup forum meta all at once like we do for topic meta etc. Fixes #918

Milestone 1.0-beta deleted