After thinking for a little while I actually think the body of a post
may be more relevant when searching for posts than the thread title.
Right now this is just a hunch and we'll have to find out how it
actually ends up working in real life.
Adds support for executing full-text search across a forum instance by
sending the `SearchPosts` message with a search query to the DB actor.
The struct used for results is mapped manually to the expected query
result as the query is embedded via raw SQL.
Adds a 'sticky' column to threads and rewrites the thread index to
take sticky markings into account when ordering threads.
Stickies are not yet highlighted in any way in the forum overview.
This is a simplification over the previous approach. The OP of a
thread is just a normal post like any other in this model, which
allows some code simplifications (and future query convenience).
This took me some time to figure out so it's useful to document in the
commit message.
When chaining messages from actors, the result type of a message (i.e.
the actual `<M as Message>::Result`) is sometimes itself a
`Result<T, E>`.
In many cases this leads to a situation where the return type of a
message sending process is something like (simplified):
Future<Item=Result<Foo, ConverseError>, Error=actix::MailboxError>
Due to the implementation of
`From<actix::MailboxError> for ConverseError` it is possible to use
`.from_err()` on these futures to convert the future's `Error` to
`ConverseError`.
The type `Result` apparently implements `IntoFuture`, which means that
due to some trait magic that's been applied somewhere in the futures
API a call to `flatten()` can "lift" the contained error if the error
types match and give us a "simple"
Future<Item=Foo, Error=ConverseError>
From that point on chaining becomes easy.
Implements a new thread rendering pipeline which all posts and the
main thread body are first converted to a `RenderablePost` structure.
During the conversion to this structure, the post body is rendered as
Markdown and the author's email address is converted into the format
required by Gravatar.
This currently breaks error handling in page render flows. To fix it
properly, the database actor should return failable futures instead of
`Result<T>` wrapped in a future.