Type-kun said:
Aren't those stored in session variables rather then cookies? I thought session variables allow arbitrary amounts of data to be stored, since they are actually just plaintext files.
Session variables are stored in cookies.
Posted under General
This topic has been locked.
Toks said:
Session variables are stored in cookies.
Geh, Rails caught me off-guard with that. That's a neat speed improvement, but Ruby manuals should be flashing "CAUTION" signs about security/size implications.
..Well, why not just move sessions to memcached/redis/db as described here, for instance? Looks simple enough to do, and speed difference is rather marginal.
Type-kun said:
..Well, why not just move sessions to memcached/redis/db as described here, for instance? Looks simple enough to do, and speed difference is rather marginal.
So you want to store session variables in the database basically?
Why do it that way? What's the benefit over just storing the read forum topic ids in the database like I suggested 3 months ago, and leaving the other session variables alone?
It seems like it would just make it harder to work with the read_forum_topics than if they were stored in a regular db table.
Toks said:
Why do it that way? What's the benefit over just storing the read forum topic ids in the database like I suggested 3 months ago, and leaving the other session variables alone?
So that session variables can be safely used to store any other data we may come up with in the future? Otherwise, even if we move topic IDs away into the database, it'll be a timebomb that will detonate sometime later.
As for storing the ids in the DB as you suggested, I'm not against that, but, as I said earlier, table for storing read topics for all users would grow as large as [topics]*[users] rows, and trimming it or storing unread topics involves frequent deletions, which could cause some trouble for the DB and requires performance tests to ensure that server will not resort to seqscans after a few days.
It seems like it would just make it harder to work with the read_forum_topics than if they were stored in a regular db table.
Nah, it will just change storage location, should not affect any API.
Type-kun said:
Nah, it will just change storage location, should not affect any API.
That's the problem. It's already hard to work with it as-is, and it will stay hard if we keep it in session variables.
Have you read the current code? It's very counter-intuitive, it took me forever to understand what it's doing.
Type-kun said:
So that session variables can be safely used to store any other data we may come up with in the future? Otherwise, even if we move topic IDs away into the database, it'll be a timebomb that will detonate sometime later.
Session variables are only intended to store small amounts of data, not huge things like read forum topics.
Source: http://guides.rubyonrails.org/action_controller_overview.html#session
"Your application has a session for each user in which you can store small amounts of data that will be persisted between requests."
"Storing large amounts of data in the session is discouraged no matter which session store your application uses."
Type-kun said:
As for storing the ids in the DB as you suggested, I'm not against that, but, as I said earlier, table for storing read topics for all users would grow as large as [topics]*[users] rows, and trimming it or storing unread topics involves frequent deletions, which could cause some trouble for the DB and requires performance tests to ensure that server will not resort to seqscans after a few days.
You're talking about what you said here?
It's not true that "Mark all as read" will require [forum-topics-count] records to be inserted. All it needs to do is update the user's last_forum_read_at to the current time. Then last_forum_read_at can take precedence over the read_forum_topics table. No insertions necessary. fyi, this is what the current code already does.
Trimming the table of old unneeded records so it doesn't gradually grow too much could be a problem, though. I guess we could run a delayed job to do this once per week or something? This should be tested for performance, yes.
Toks said:
You're talking about what you said here?
It's not true that "Mark all as read" will require [forum-topics-count] records to be inserted. All it needs to do is update the user's last_forum_read_at to the current time. Then last_forum_read_at can take precedence over the read_forum_topics table. No insertions necessary. fyi, this is what the current code already does.
Trimming the table of old unneeded records so it doesn't gradually grow too much could be a problem, though. I guess we could run a delayed job to do this once per week or something? This should be tested for performance, yes.
I see, that should work, however trimming from time to time is definitely necessary. Also, last_forum_read_at should be updated at every topic read as necessary, not just at "mark all as read" - but I think it is already that way.
If a delayed job is created, it should also call reindex after deleting records in the table. This, along with autovacuum, should take care of any performance issues caused by deletions.
something odd about auto-add tags happening in post #1724851
on first glance the tag "panties" is spelled right but yields only one post, as contrasting to 158k is actually has.
upon clicking the erroneous tag, it has been turned into "_panties" on the search box instead.
using the any of the two [edit] functions also yields "panties" with spacing as if it was a normal tag, but upon committing changes, it retains the "_panties" value.
z905844 said:
something odd about auto-add tags happening in post #1724851
on first glance the tag "panties" is spelled right but yields only one post, as contrasting to 158k is actually has.
upon clicking the erroneous tag, it has been turned into "_panties" on the search box instead.
using the any of the two [edit] functions also yields "panties" with spacing as if it was a normal tag, but upon committing changes, it retains the "_panties" value.
Tag names don't display underscores correctly. issue #1736
Just remove the underscore from the beginning of _panties.
z905844 said:
using the any of the two [edit] functions also yields "panties" with spacing as if it was a normal tag, but upon committing changes, it retains the "_panties" value.
Your confusion and this happening could also be because both _panties and panties were on the tags list on the post simultaneously, thus obviously, the correct one also was on the editing fields.
Vanobond said:
And how to solve this problem?
Set the referrer to blank, or to http://danbooru.donmai.us/.
Toks said:
Set the referrer to blank, or to http://danbooru.donmai.us/.
I do not understand a bit, I can download preview, but not full-sized images, it is my problem
Toks said:
Previews allow hotlinking. Full sized images don't allow hotlinking.
To get around it, change the referrer like I said.
Please can you explain what is referrer? And where do I need to set it? I just pick link from XML add http://danbooru.donmai.us/ and try to download, so I cannot understand what I need to do.
Updated
Vanobond said:
Please can you explain what is referrer? And where do I need to set it?
http://en.wikipedia.org/wiki/HTTP_referer
I don't know what you're using to download images, so I can't explain where to set it.
Toks said:
http://en.wikipedia.org/wiki/HTTP_referer
I don't know what you're using to download images, so I can't explain where to set it.
I think I understood what I have to do, thanks :)
UPD: Yeah, It has started working, I am very grateful to you.
Updated