[buddypress-trac] [BuddyPress] #3177: member profile forum screens
buddypress-trac at lists.automattic.com
buddypress-trac at lists.automattic.com
Mon Apr 25 13:20:09 UTC 2011
#3177: member profile forum screens
--------------------------+-----------------
Reporter: DJPaul | Owner:
Type: enhancement | Status: new
Priority: critical | Milestone: 1.3
Component: Theme | Version:
Resolution: | Keywords:
--------------------------+-----------------
Comment (by boonebgorges):
I've started poking around with "replied to". It is going to be tricky.
bbPress does not appear to have any native method for getting topics
replied to, perhaps because it would necessarily involve a join and thus
be ugly. It seems to me that there are two strategies we might consider.
1) Write our own query. Or, rather, filter bbPress's query and manipulate
it manually, like BP already does to ensure that group privacy settings
apply in the forum directory. The SQL would have to look something like
(this is totally pseudocode off the top of my head, probably won't work!)
{{{
SELECT DISTINCT p.topic_id, t.* FROM $bbdb->posts p LEFT JOIN
$bbdb->topics t ON (t.topic_id = p.topic_id) WHERE p.poster_id =
{$user_id}
}}}
This only involves a single join, which shouldn't be terrible given that
the topics table is necessarily smaller than the posts table, but if we
structure it as a filter on the BB_Query object, then we may be adding it
to an already-existing join. I don't know.
2) Store topics-replied-to as a piece of usermeta (kinda how bbPress
currently deals with favorites), so that the Replied To panel will involve
querying bbPress for specific topics. This seems better than (1) in part
because it avoids messing with the bbPress query. On the other hand, there
are a few things to consider: (a) it won't apply to existing posts unless
we write an installation routine that loops through existing members and
gets their posts (this would be for 1.2-1.3 upgrades only), and (b) the
usermeta itself could get quite large if someone is extremely active on
forums. That means that the usermeta value itself could get very, very
large (especially as topic_ids have more digits). Also, it could mean some
inefficiency in BB_Query if the numbers are big - I have no idea how
efficient IN(x) queries are when x is a very long string.
--
Ticket URL: <https://trac.buddypress.org/ticket/3177#comment:1>
BuddyPress <http://buddypress.org/>
BuddyPress
More information about the buddypress-trac
mailing list