Show Likes
This section allows you to view all posts where this member received or gave a like to.
1
Let's remove duplicate code!
Code: [Select]
/Sources/Post.php (working copy)
@@ -243,8 +243,6 @@
);
}
- $context['post_error'] = array('messages' => array());
-
// See if any new replies have come along.
if (empty($_REQUEST['msg']) && !empty($topic))
{
2
So I've been thinking about searching and the way searching works and I've concluded a number of things.
1. I want Sphinx and ElasticSearch in the core
Both Sphinx and ElasticSearch are pretty mature. Both have live update features now, so there's no reason we can't support them both with a sort of push mechanism (rather than Sphinx's pull mentality, like the old API was geared for)... the API needs rewriting to support either anyway and I might as well do it all together.
2. I want to natively support other types of data than posts.
The current setup doesn't support anything other than posts and I want to natively offer support for other stuff - calendar, helpdesk etc. The backend can support these extra things with some work, and pushing these also allows nice support in both ES and Sphinx.
3. It adds some nice feature parity with other systems without adding a ton of headaches for support.
XenForo offers ES with a $60 plugin, though I'm not entirely sure why. IPB has Sphinx in the core. Neither appears to have a huge support overhead because of them. And for the most part once they're done, they're done from our point of view.
4. The most controversial aspect of this is what I want to propose last: ditching unindexed searching.
Right now, the default searching method in Wedge is as it is in SMF: no index. It's slow, and doesn't scale beyond a few tens of thousands at peak. In fact, where we are right now on wedge.org is probably about the limit of what we can do with an unindexed DB before performance starts to go nuts. (40k is really the upper limit)
Now, partly this is because we've never configured it to be anything else, and most people just wouldn't know to do so because they wouldn't know any better. Now that's fine, because we know that people don't generally touch the settings unless they're directed - but using the search index would deliver better search performance from about 1k posts and up (and largely a push in performance terms for where things are right now for fresh installs)
I see no reason why 'no index' ever needs to be a valid search type. I'd suggest dropping that entirely and using the 'no index' option to mean 'no searching'. And then leaving the other index types to be actual index types, which would simplify the search code as well (and properly allow for it all to be segregated back to the APIs, some of which has already occurred but plenty more still to do)
This would leave us with three working search types (standard - formally known as custom, ES, Sphinx), of which 'custom' would be set as default on installation and would be populating posts as they are created (rather than having to deal with a huge index creation at once)
ES and Sphinx are both VPS level options, but there's no reason we can't have people pushing content to these indexes while using the custom index - plus of course there are always options for rebuilding indexes.
Does any of this make sense? Any questions?
1. I want Sphinx and ElasticSearch in the core
Both Sphinx and ElasticSearch are pretty mature. Both have live update features now, so there's no reason we can't support them both with a sort of push mechanism (rather than Sphinx's pull mentality, like the old API was geared for)... the API needs rewriting to support either anyway and I might as well do it all together.
2. I want to natively support other types of data than posts.
The current setup doesn't support anything other than posts and I want to natively offer support for other stuff - calendar, helpdesk etc. The backend can support these extra things with some work, and pushing these also allows nice support in both ES and Sphinx.
3. It adds some nice feature parity with other systems without adding a ton of headaches for support.
XenForo offers ES with a $60 plugin, though I'm not entirely sure why. IPB has Sphinx in the core. Neither appears to have a huge support overhead because of them. And for the most part once they're done, they're done from our point of view.
4. The most controversial aspect of this is what I want to propose last: ditching unindexed searching.
Right now, the default searching method in Wedge is as it is in SMF: no index. It's slow, and doesn't scale beyond a few tens of thousands at peak. In fact, where we are right now on wedge.org is probably about the limit of what we can do with an unindexed DB before performance starts to go nuts. (40k is really the upper limit)
Now, partly this is because we've never configured it to be anything else, and most people just wouldn't know to do so because they wouldn't know any better. Now that's fine, because we know that people don't generally touch the settings unless they're directed - but using the search index would deliver better search performance from about 1k posts and up (and largely a push in performance terms for where things are right now for fresh installs)
I see no reason why 'no index' ever needs to be a valid search type. I'd suggest dropping that entirely and using the 'no index' option to mean 'no searching'. And then leaving the other index types to be actual index types, which would simplify the search code as well (and properly allow for it all to be segregated back to the APIs, some of which has already occurred but plenty more still to do)
This would leave us with three working search types (standard - formally known as custom, ES, Sphinx), of which 'custom' would be set as default on installation and would be populating posts as they are created (rather than having to deal with a huge index creation at once)
ES and Sphinx are both VPS level options, but there's no reason we can't have people pushing content to these indexes while using the custom index - plus of course there are always options for rebuilding indexes.
Does any of this make sense? Any questions?
3
This was due to two bugs, actually...!
Fixed!
Fixed!
4
hehehe award image instead of user avatar
6
Pete's next post will be his 14k-th!
14k
so it doesn't appear so big. :)
7
Team board / Re: Notification system for Wedge (patch file)
live627 « on June 16th, 2013, 09:19 AM »
Here's what I've done with it. Attached is a patch of the changes I've made to the core and a modified topic subs plugin.
8
To be honest, there are only actually two kinds of loop, for and while. Everything else, including foreach, as well as bastardised for[1] is straight up syntactic sugar variations around for and while. A foreach is really just a for that iterates over an array, you could write the foreach as a for but it'd be longer and uglier especially with a hash key array - but it doesn't change the fact it could be done.
If you understand the for loop, that's pretty much the only one you need to really worry about (because every language I've ever used has *some* variation of it... even assembler itself essentially does this)
If you understand the for loop, that's pretty much the only one you need to really worry about (because every language I've ever used has *some* variation of it... even assembler itself essentially does this)
| 1. | Of the kind like for (;; i++) syntax which is perfectly valid. |
9
Now can notify you whenever you get an award.
10
The moved topic annoyancesnotices via. PM are really driving me crazy. So I decided to extend the notification system to include these. If a member moves their own topic, they won't get a cheeseburgernotification because they obviously already know about it. Or, I hope they do. Hmm, maybe.... ZOMBIE INVASION!!
 |