• Fur Affinity Forums are governed by Fur Affinity's Rules and Policies. Links and additional information can be accessed in the Site Information Forum.

Changes to favorite pages' URL

femboy tiger

New Member
I have a lot of favorite links on FA, and I used to be able to go back to something a favorited a long time ago by changing the URL page name to get from one page (ex. second page) to another (ex. fourtyth page)

Ex.
www.furaffinity.net/favorites/username/2
to
www.furaffinity.net/favorites/username/40

But now, the URL has changed to something like this
www.furaffinity.net/favorites/username/638637199/next

Where I can only go from one page to the next available page, and the numbers (638637199) aren't in order

Is this just a new URL system that FA has, or is there a way to change it back to the old way?
 

Dragoneer

Site Developer
Site Director
Administrator
This is a new URL system the favorites page has per better performing pagination on these pages. It reduces database load over time. However, it does links to any specifics favorites pages except the base page.
 

femboy tiger

New Member
This is a new URL system the favorites page has per better performing pagination on these pages. It reduces database load over time. However, it does links to any specifics favorites pages except the base page.

Sorry, did you mean it doesn't link to any specific favorite page except the base page?
 

PanzerschreckLeopard

Active Member
So what are we supposed to do if we need a pic that's on, say, page 350? Do they expect us to hit "next" 350 times?

Oh, but there's no search bar either in the fave or galleries...you know, something that'd actually be useful for looking past the first 10 pages. But noooo, that would be actual work, let's just make it even less useable instead!
 
Last edited:

PanzerschreckLeopard

Active Member
been nearly a week and no response, is the issue just gonna be ignored?
 

Dragoneer

Site Developer
Site Director
Administrator
Sorry, did you mean it doesn't link to any specific favorite page except the base page?

This is correct. Only the base page can be properly bookmarked now.

been nearly a week and no response, is the issue just gonna be ignored?

Not ignored, no. You mentioned needing a specific picture on, say, page 350 of a user's favorites. At what point do you need to favorite a specific page Favorites page -vs- favoriting the picture? Because page 350 may not be page 350 tomorrow, or even an hour from now. That data is fluid and updates/changes all the time.
 

quoting_mungo

Well-Known Member
Not ignored, no. You mentioned needing a specific picture on, say, page 350 of a user's favorites. At what point do you need to favorite a specific page Favorites page -vs- favoriting the picture? Because page 350 may not be page 350 tomorrow, or even an hour from now. That data is fluid and updates/changes all the time.
I think it's more "I know I favorited that piece I got from an artist around three years ago, and I favorite about 100 pages of submissions every year" - if there's no way to jump to older favorites pages anything past maybe the first handful might as well not be favorited.
 

MissNook

Well-Known Member
Yep I agree. I have only 5 pages but it's already a waste of time to click 5 times on the next button to come back to my first favorites things...
 

Dragoneer

Site Developer
Site Director
Administrator
I think it's more "I know I favorited that piece I got from an artist around three years ago, and I favorite about 100 pages of submissions every year" - if there's no way to jump to older favorites pages anything past maybe the first handful might as well not be favorited.
Which I can understand to some degree, but it make more sense to favorite individual items because a favorites list (in theory) is ever changing... and pages are never the same.
 

quoting_mungo

Well-Known Member
Which I can understand to some degree, but it make more sense to favorite individual items because a favorites list (in theory) is ever changing... and pages are never the same.
Neer, you know I like you, but right now you are being a huge derp. :p The point is that having something in your favorites is only really useful if you can find it again. Totally understand there being a performance concern, but having some way of skipping to an arbitrary favorites page would still be useful particularly for users with a ton of favorites.
 

Dragoneer

Site Developer
Site Director
Administrator
Neer, you know I like you, but right now you are being a huge derp. :p The point is that having something in your favorites is only really useful if you can find it again. Totally understand there being a performance concern, but having some way of skipping to an arbitrary favorites page would still be useful particularly for users with a ton of favorites.
I'm just trying to understand the problem a bit better in relation to their site usage.
 

quoting_mungo

Well-Known Member
I'm just trying to understand the problem a bit better in relation to their site usage.
I'll be honest: I'm not sure where the disconnect is.
I personally don't really have enough favorites to make it a huge bother, since I'm stingy with them, but for people who favorite a ton of stuff, the change means they can't edit the page URL to jump to an arbitrary page. That means that the longer it's been since they favorited something, the less likely they are to see it again, and the more pages they'll need to load before getting to a given piece beyond the first two pages. (If a pagination thingy like long threads in the forums have was added, it'd alleviate that issue at least to some degree.)
 

Stratelier

Well-Known Member
I'm just trying to understand the problem a bit better in relation to their site usage.
Basically, this problem. As the favorites pages are no longer actually paginated, there is no way to jump to an arbitrary position within the list when the user wants to.

(And if you're wondering just who would want to do that -- that's the wrong question.)
 
Last edited:

MissNook

Well-Known Member
I'm just trying to understand the problem a bit better in relation to their site usage.
If you want an example, I fav not a lot of things, which are things I want to be able to find back. It's for inspiration as an artist and for technical understandings.
What happened before the update: I wanted to find back a piece with a special light and fur design in it, I went to my fav; knowing I fav it at the beginning, went to my last page with the address and find the piece I wanted to look at.
What happened after the update : I wanted to find back a piece with a special light and fur design in it, I went to my fav; knowing I fav it at the beginning, click 5 times on the "next" button just to go to my last page and then find it.

I have only 5 pages and I'm wondering if I should keep favorite things because I won't be able to find quickly what I want. I don't think that's the goal of the functionality.

By the way I don't see any interest in this feature anymore. If it's to say you like something, then putting a comment under the image will be far more interesting than just putting it on a fav list where I would not be able to find it back.

Well, I hope that helps you understand a little better.
 
I'm just trying to understand the problem a bit better in relation to their site usage.
Basically, this problem. As the favorites pages are no longer actually paginated, there is no way to jump to an arbitrary position within the list when the user wants to.

(And if you're wondering just who would want to do that -- that's the wrong question.)

Exactly as @Stratelier said. This system may be easier on the servers (though tbh that could only be the case with a badly designed database) but it's a nightmare to users. Favorites are broken now as they lost all functionality.
Imagine a pile of items if you will, before this system came into being we could simply go to a specific position in the pile and find an item or at least get close to its position, easy peasy. But now what we have to do is go through the pile from the top to the position we want to find. Now what if I want to go to my last page? I need to open ALL pages before it and the server has to give me ALL the submissions in between.
Now I'm not saying bring back the old system if this really helps the servers, but what about putting a small box where we can input the page we want? That way the servers have less load and the favorites are again useable. Right now faves are broken as they loose the functionality they exist to serve, i.e. save things to look at them again later.

All that said, why would this method help the servers? Why not use a simple list? That way if a user wants page 123 the server only needs to get items from index 122*24 through 123*24. Generalized with P as the page and N as the number of subs per page you get a simple interval of [(P-1)*N , P*N].
 

Stratelier

Well-Known Member
All that said, why would this method help the servers? Why not use a simple list? That way if a user wants page 123 the server only needs to get items from index 122*24 through 123*24. Generalized with P as the page and N as the number of subs per page you get a simple interval of [(P-1)*N , P*N].
... You've not actually worked with database queries before, have you?

The database is not allowed to cache the intermediate steps of a query because it has no guarantee that said cache will be useful for future queries; it must (in principle) start from scratch every query. So if I'm viewing pages in someone's gallery (favorites, etc.), even if I'm just viewing pages sequentially, the processing load per page is proportional to P, and the total (across all pageviews) processing load increases quadratically (P + P+1 + P+2 + P+3, etc.) not linearly.

Say somebody has over 10,000 favorites and I want to view page 100 (at 48 per page). If I have all content enabled on my end (e.g. maybe I'm viewing my own page) then the server can simply look up, unfiltered, whatever index is responsible for holding this -- the processing time of an index scan is proportional only to the size of said index (regardless of P).

However, say I have mature and adult content filtered out, and the user's favorites are a roughly evenly-distributed 50/30/20 mix between General/Mature/Adult. In this case an index scan is not enough and the server must manually review every item individually for its content label. This could result in any of the following scenarios:
- If I have all content enabled, page 100 is guaranteed to be at offset 4800.
- If I have adult content filtered off, page 100 might be an offset of ~6000.
- If I am viewing General content only, page 100 might be an offset of ~9600.
- If I am searching Adult content only, page 100 might be an offset of ~24000.

In all but the first case, exactly how many rows the server must process before it finds our page is unpredictable, so it has to do the legwork every time. Literally EVERY SQL manual will tell you to avoid writing queries with high offsets for this reason.

The general alternatives to page offset queries are:
- Run a non-paginated query and cache the results yourself (avoids having to repeat the query just for pagination, but can cause sync issues between cache and database)
- Implement pagination based on absolutely defined criteria (not page offsets, which are dynamic)

Option #2 is generally the better choice, provided there are enough features on the front-end to replace what functionality we previously had.

Dragoneer, at least add "first/last" buttons to complement the "prev/next" buttons.

I would also recommend a scondary URL format that allows us users to supply arbitrary criteria. (e.g: /favorites/username/next/2017/june/ ) It could be something simple, even if it only just issues a URL redirect to the primary URL of that page (e.g. /favorites/username/next/_id_number )
 
Last edited:
... You've never worked with database queries before, have you? You're not wrong, but the actual processing load on the database is always directly proportional to P and this is repeated for every query -- the database is not allowed to cache the intermediate steps of a query because it has no way of knowing whether the next query will be similar or vastly different; it must (in principle) start from scratch every time.

Say somebody has over 10,000 favorites and I want to view page 100 (at 48 per page). If I have all content enabled on my end (e.g. maybe I'm viewing my own page) then the server can simply look up, unfiltered, whatever index is responsible for holding this -- the processing time of an index scan is proportional only to the size of said index (regardless of P).

However, say I have mature and adult content filtered out, and the user's favorites are a roughly evenly-distributed 50/30/20 mix between General/Mature/Adult. In this case an index scan is not enough and the server must manually review every item individually for its content label. This could result in any of the following scenarios:
- If I have all content enabled, page 100 is guaranteed to be at offset 4800.
- If I have adult content filtered off, page 100 might be an offset of ~6000.
- If I am viewing General content only, page 100 might be an offset of ~9600.
- If I am searching Adult content only, page 100 might be an offset of ~24000.

In all but the first case, exactly how many rows the server must process before it finds our page is unpredictable, so it has to do the legwork every time. Literally EVERY SQL manual will tell you to avoid writing queries with high offsets for this reason.
Doh! Had forgotten about the rating restrictions DX
You are right, didn't consider that parsing.

Played around a bit with my local fa database and populating the faves list at every page requests does take a LOT more time if any kind of content restriction is in place, my fault for not thinking about the rating factor.

Was thinking that maybe they could have different fields per user for different rating restrictions and have an A/B database system. Whenever a user adds a favorite the B db is updated and A is used for requests while this is done then A is substituted with B in requests and they can switch like this. The same would be done whenever a submission's rating is changed. Since it's an uncommon occurrence it would have to be done often. The first case would take only milliseconds as it only needs to update a single row. The second would take more but as said it's an uncommon occurrence (I'd say in the order of 10^3 per day?) and the resulting database would be easier to parse as you'll only need an offset. Furthermore any request that changes ratings can be made so it delays other requests to make sure there are no "ghosts".
I've tried it a bit with a local database (filled it up with dummy data to parse, about 5000000 subs and 500000 users, using a laptop so scaled it down) and it does make rating-restricted requests for galleries, favorites and such faster while not changing the time needed for global searches. Idk how feasable this is tough as I have no idea how big FA's database really is, with my dummy one updating 500000 users took less than half a second (using an m.2 ssd).
 

Stratelier

Well-Known Member
Was thinking that maybe they could have different fields per user for different rating restrictions and have an A/B database system. Whenever a user adds a favorite the B db is updated and A is used for requests while this is done then A is substituted with B in requests and they can switch like this.
The concern isn't about concurrent database access, but rather that the raw efficiency of a given query (rows processed vs. returned) is always inversely proportional to the specified query offset (relative to limit).
 

PanzerschreckLeopard

Active Member
At what point do you need to favorite a specific page Favorites page -vs- favoriting the picture? Because page 350 may not be page 350 tomorrow, or even an hour from now. That data is fluid and updates/changes all the time.


Okay, what if you can't remember the name of the artist, and they have fuck-all for tagging. (god that's another thing I hate....artists that give no description, no tags, and leave all the gender/species/etc tags as "any." How do they expect their art to be found? But that's a whole different matter...) Anyway, so we don't know the artist, we can't find it with the search bar or browse option. All that is remembered is that the last time it was found in your own faves, it was no less than 350 pages back.

"Oh it might not be 350 any more" is zero help whatsoever. It would still be a lot easier to jump to that page to begin the search, and save several hours of useless clicking.

Also, would it be at all possible to add a search bar to the gallery and faves like deviantart does? Regardless of how the pages now work, it would make it much easier to find pics (either specific pics, or just any of the fetish) that is in your faves, or in the gallery of an artist who has thousands of uploads. (The latter case , it would be particularly helpful if the artist does a few pics you really like, but you have to sift through hundreds that you really really don't want to even glimpse, to find them)
 
R

RinjiPantera

Guest
Okay everyone! Listen up! I managed to find a moderate workaround to the problem. Mind you, it'll only let you jump to anywhere in your own faves and not anyone else's. If you go to the menu under My FA and into Page Management, then select Favorites, you'll find where you would normally be able to select specific faves or batches of faves you might want to remove. However, if you add a / and a number or just click Next 72 on the lower right hand corner of the page, the URL will show the /1 at the end and you can THEN change that number to whatever you want to jump through your faves to a more approximate location without your entire Faves section. This turns the Faves management page into a pseudo old-style Faves section under your FA account.

In other words, you end up in this URL: User control panel -- Fur Affinity [dot] net
You can then add a /1 at the end to get this: User control panel -- Fur Affinity [dot] net
That number can then be changed to whatever number you want, based on have many faves you have, such as:
User control panel -- Fur Affinity [dot] net

Now bear in mind, that it's not quite as accurate as the original old system in Faves itself, but it'll at least allow you to jump as far back into all your faves a helluva lot faster.

Hope this helps alleviate some tension over this whole Faves issue. I'm personally thinking of going through my entire faves and removing ones that aren't "absolute" favorites, to trim them down a fair bit.
 

jaredwolf

New Member
Thank you, RinjiPantera, this is a huge help!

I don't know how difficult it be to add a search bar in the faves like DA, but it would be a nice addition.
 

Spam7

New Member
RinjiPantera, genius!

I created an account just to thank you!

Furthermore, yeah, a search bar in faves would be an excellent addition.
 

Laugh

New Member
...You mentioned needing a specific picture on, say, page 350 of a user's favorites. At what point do you need to favorite a specific page Favorites page -vs- favoriting the picture? Because page 350 may not be page 350 tomorrow, or even an hour from now. That data is fluid and updates/changes all the time.

I made an account to mention this; I may be the exact user your database hates, but I use favorites from other artists as a form of content discovery. I've often gone to other artist's pages who favorite a good amount and use the page number to seek back in time, seeing what art I might've missed before I was on the site or wasn't looking in the right places. Ultimately this is sounding like it's a bigger part of the issue of content searching and discovery.
 
Top