Create a randomizer for hentai exactly like https://mangadex.org/manga :planned:

[GenuineSounds]

Simple enough, hentai never shows up on the manga randomizer so it would be nice to have a hentai only page (https://mangadex.org/h-manga or https://mangadex.org/hentai) or at least change the behavior of the https://mangadex.org/manga randomizer to follow the users' settings for hentai being shown or not.

Let me know if it's a good idea.

 

[Teasday]

@GenuineSounds Just to let you know, we'll be implementing this sooner or later. Within days at worst.

Oh, and by "this" I mean making the regular randomizer work based on the H filter.

 

[BadWithNames]

@Teasday Will you be able to exclude tags in the randomizer? Like Yaoi/Yuri/Sexual Violence/Gore etc

 

[BeGo]

Agree with @genuinesounds, no need for the separate randomiser. :)

 

[DANDAN_THE_DANDAN]

At long last I will be able to binge fifty different loli hentais

 

[Teasday]

_{@BadWithNames posted:}

Will you be able to exclude tags in the randomizer? Like Yaoi/Yuri/Sexual Violence/Gore etc

Technically yes I could write that but at that point I'm starting to worry about performance.

Let me think about it.

 

[Kitsunebi]

It'd also be nice if you could set parameters for the randomization. For example I want a random series that's tagged shoujo/4-coma/completed or something like that if it doesn't affect performance

 

[GenuineSounds]

@Kitsunebi I'm not sure if MD uses SQL or something similar but as long as the queries are simple, performance isn't usually an issue. Doing something like a tag exclusion/inclusion search is trivial for a database. It would render the same performance as sorting as we have it now. Obviously the caching mechanisms are helping the normal sorting at the moment but unless a user had a bunch of inclusive search parameters it wouldn't affect performance at all.

 

[sterven]

Oh my it's finally happening thank you

 

[Teasday]

_{@GenuineSounds posted:}

I'm not sure if MD uses SQL or something similar but as long as the queries are simple, performance isn't usually an issue. Doing something like a tag exclusion/inclusion search is trivial for a database. It would render the same performance as sorting as we have it now. Obviously the caching mechanisms are helping the normal sorting at the moment but unless a user had a bunch of inclusive search parameters it wouldn't affect performance at all.

Tag exclusion by itself is, while not trivial, not really a problem. The randomizer however takes into account the user's language filter and looks only for manga with at least one chapter in one of the selected languages (meaning the query has to look through all the chapters, not just the manga entries), and now we're also adding H as a variable to that mix. It all adds up to quite a bit of table joining.

That's why proper caching is going to be important. While it wouldn't be a much of an issue to let this work uncached since the random manga requests are normally quite rare, doing that would open up a gaping attack vector for DDoS'ers.