| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Postgres
Update README with basic information on Multi
(cherry picked from commit 01188a82ab736a8975c73ac5ec12621426bf6bf2)
|
|
Been wanting to do this for a long time - using an integer index into an
array that changes once in a while is way too fragile. Doubly so when
said indices are also used in filters and URLs that can't be updated
every time a new resolution is added.
|
|
|
|
https://vndb.org/t2520.259
|
|
https://vndb.org/t3599.201
|
|
This touches a bunch of things:
- Adds a new first-class database entry type
- Removes the d+.+.+ BBCode link syntax, adds a new d+#+ and d+#+.+
link syntax (references have been updated where possible)
- Adds a new dependency on Text::MultiMarkdown
|
|
This is based on the API that I described in https://vndb.org/t5564.12
It's mostly bug-compatible with the old bb2html(), main differences:
- <br /> -> <br> for no reason
- Doesn't sporadically add a wrong </div>
- $rmwhitespace now also after [/code]
Most of the test cases were contributed by flan <flan@flande.re>
|
|
The database has grown and we're on SSDs now, so it's good to revisit
these timings and see what needs optimizing, if anything.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes the relation graphs useful again for several large (mostly)
independent graphs that are sometimes linked together by unofficial
relations.
e.g. https://vndb.org/t8985
|
|
|
|
|
|
|
|
I never use it. And it's scary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This removes the reliance on sort() to provide meaningful ordering (the
keys aren't always good for ordering) and removes the 'order' hack used
for (vn|prod)_relations.
|
|
Now that graphviz knows the actual strings, it has a better opportunity
to create better graphs.
(Most of them still look messy tho)
|
|
|
|
|
|
The API IP address doesn't change often, but we don't want months of
downtime when it does.
|
|
|
|
|
|
I'd have preferred to stick with XHTML 1.0, but unfortunately browsers
won't allow you to use modern Javascript APIs with an older doctype.
Note that most pages don't actually validate correctly as HTML5, I'm
relying on browsers to be lenient.
In either case, I'd like VNDB to stay valid XML (XHTML5, then), and
luckily that shouldn't be a problem.
|
|
They had to be deleted from the database at some point, otherwise we
still have thousands of easily-cracked password hashes in the database.
Note that I could have opted to use scrypt on top of the sha256 hashes
so the passwords would remain secure without needing to reset
everything, but doing that after one year of switching to scrypt is
likely not worth it. Everyone who still actively uses his account has
already been converted to scrypt, everyone else should just reset their
password whevener they decide to come back.
|
|
Turns out the anime data hasn't been updated in a few months. Oops.
|
|
That should be the last thing to convert to the new schema.
|
|
Turns out that fetching whether or not you have unread notifications
(done on every pageview if you're logged in) was pretty slow. The index
speeds up both that query and the "my notifications" view.
The extra purge for old notifications for users with more than 500
notifications ensures that the index stays effective for the unread
notifications count. Otherwise it'll have to read half of the
notifications table anyway to check the 'unread' filter.
|
|
Hopefully prevents issues like https://vndb.org/t3599.53
|
|
This was more trivial than I had expected. I already took ipv6 into
account when rewriting the API for AnyEvent (including the use of
norm_ip()), so that part was fine. The only part I had to fix was the
listening socket, and I had to ensure that the $c->{ip} was correct. The
first was easy, and the latter was properly handled by AnyEvent
automatically. Looks like AnyEvent automatically 'unpacks' IPv4-mapped
IPv6 addresses, so I didn't have to deal with that myself.
|
|
This is to save system resources when a misbehaving client keeps sending
commands while it's being throttled. It also protects against trivial
DoS attacks.
|
|
AE::timer accepts a time interval as argument, not a complete
timestamp. So the monthly cron job hasn't run in a while...
|
|
|
