Thread support

Threads without GROUP BY are really PITA. Thread is like some hidden object that can only be described using aggregation SQL functions which makes Views integration for threads like hitting a wall by the head of developer.

I thought about MySQL VIEWS but they have terrible performance as far as I read cause MySQL does very poor job with indexes + VIEWS. Another option would be to have a separate table updated by triggers, which could explicitly store thread properties. But that would prolly take more work and triggers have their own problems.

Maybe we should avoid Views integration for threads until stable Views 3.x which should have better support for GROUP BY.

Unless someone has some very good idea how to implement that, I'm going to postpone thread support atleast until Views 3.x stable release.

Seems like I have found a way to workaround this without GROUP BY but by using SQL tricks that emulate MAX() and MIN(). Following query returns either first or last messages in the corresponding threads depending on using ">" or "<" in JOIN condition of pmi2. http://dev.mysql.com/doc/refman/5.0/en/example-maximum-column-group-row.html

SELECT pmi.*,m.body FROM pm_message m
INNER JOIN pm_index pmi ON pmi.mid = m.mid 
LEFT JOIN pm_index pmi2 ON pmi.uid = pmi2.uid AND pmi.thread_id = pmi2.thread_id AND pmi.mid > pmi2.mid 
WHERE pmi2.thread_id IS NULL ; 

Note that we still don't do aggregate query cause it's simple message listing. Thus, we won't have COUNT() in the same query (e.g. to get number of messages in a thread). Better thread support will become possible with Views 3.0 and full thread support IMHO will be possible only if thread becomes a full object with properties stored in own table.

I've committed initial basic supports for thread: we still operate on messages table, but by using special filters ("last message" or "first message") that implement tricks described above we turn message listing into thread listing and because every message has a thread, we have thread_id automatically too.
Message counts and participants are fetched in separate queries during pre_render stage. It is probably little slower than Privatemsg, but should be fast enough.