6 replies to this topic

[kraeth]

Greetings, fellow tomatoes.

 

So, as I search for just about anything most content is something that I've already read. Thus, having an option to exlude followed material or an option to mark series you're not interested in for search purposes would be really, really great.

 

Thanks for keepings this superb site up, love you all!

[Dafortminor]

Added to the suggestions list. 

 

-Daffy

[mannewe]

I second this. It would greatly improve the search to exclude the already followed titles.

 

In the UI (yes, I know it's generated code):

diff -r a5d4f4b0cbc6 -r 0749a0feb96a search.htm
--- a/search.htm	Sun Sep 20 20:13:26 2015 +0100
+++ b/search.htm	Sun Sep 20 21:17:58 2015 +0200
@@ -813,6 +813,13 @@
             </td>
         </tr>
         <tr>
+            <td style="text-align: right; font-weight: bold;">Include My Follows:</td>
+            <td style="text-align: left; vertical-align: top; padding: 8px 0;">
+                <label><input type="radio" name="follows" value="y" checked="checked"/> Yes</label>
+                <label><input type="radio" name="follows" value="n" /> No</label>
+            </td>
+        </tr>
+        <tr>
             <td style="text-align: right; font-weight: bold; border-bottom: 1px solid #999999;">Type:</td>
             <td style="text-align: left; vertical-align: top; padding: 8px 0; border-bottom: 1px solid #999999;">
                 <label><input type="radio" name="type" value="any" checked="checked"/> Any</label>

On the backend a conditionally added clause along those lines:

WHERE titleid NOT IN (SELECT titleid FROM follows WHERE userid = :1)

The subquery is costly, but if made optional (non-default) this should not impact query time too much. Yes, someone following all the titles could run into db timeout (2006 or sth like that), so I'd give this option only to users with less than % and more than % follows . BTW this - and any reference to follows - can be probably optimized (e.g. http://stackoverflow.com/questions/3645794/sql-not-in-subquery-optimization-or-alternatives).

 

Yes, I can code this for you if needed - it would really ease-up my browsing...

[Grumpy]

I have this issue with steam as well. Wish it had option for hiding stuff I already own. But as above user mentions, I do fear for the search query's cost. (guessing why steam doesn't do it either) Complex queries are already quite expensive and there are tons of users with well over thousand follows. I suspect they're the ones who need it the most. (more technically) I also can't change clustered composite index as the SO would suggest because the follow table is IPB made and would screw up with other expected behaviours of the current clustering.

 

I would put this under not likely.

[Halo]

There's a userscript that filters out followed manga: batoto myfollows


 

I have this issue with steam as well. Wish it had option for hiding stuff I already own.

http://www.enhancedsteam.com does that.

[Daktyl]

There's a userscript that filters out followed manga: batoto myfollows

 

That's certainly one way of doing it, but it's not as smooth as a native option (which would be what most people want). You have to either visit My Follows or click the button to make sure your follows are synced with the localStorage database in your browser.

 

That being said, it's nice that this exists and when this topic comes up in the future I'll make sure to reference it

[mannewe]

@Grumpy

A big rule in performance optimisation is "don't optimize prematurely". Obviously, don't ever do it if performance impact is too large, but it's near-impossible to guess the impact beforehand. For one thing, the userscript mentioned by Halo effectively forces users to make multiple queries instead of just one. That effectively doubles the effort for db engine (unless you use in-memory indexes, which is unlikely). If the reason for not going in this direction is due to potential performance bottlenecks, then do it (e.g. without UI at first) and test it, analyze actual performance, drop it afterwards. Problems usually crop up in unexpected places. BTW, if search performance is ever the issue you should introduce a request limit (e.g. one per HTTP session per every 5s): that's an annoying but accepted solution.

Also: you can get away from subclauses by increasing query length ;P