| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
I'm surprised I haven't been able to find a combination of filters that
would generate an SQL query that would run more than 300ms or so.
PostgreSQL is amazing!
|
|
The original language is the language of the first release of the VN,
and is cached in vn.c_olang. (Geez, the vn table has more caching
columns than actual information >.>)
|
|
Because the site never looked good in IE7, and the new filter system
doesn't work *at all*. (Doesn't work correctly on IE8 either, but I'll
try to fix that)
|
|
|
|
Had to fix some bugs here and there and add some new functionality to
the abstractions at some places, but it appears to be working now. There
are still a few TODOs left, I'll get to those in a bit.
|
|
And rewrote the expand/collapse JS/CSS code so that the difference
between expanded and collapsed view is merely the class of the
containing table. This way the JS code doesn't have to pass through the
table rows and is thus noticeably faster for larger tables (i.e. /p65).
|
|
It does not use split() anymore, the input string is parsed in a single
pass using a global regex. It's now a lot faster on larger input. The
page generation time of /t937 went back from ~350ms to ~55ms (on the
beta, the production server is slower).
Also made several tiny improvements while I was at it:
- multiple successive newlines aren't removed within [code]
- truncating a message with $maxlength also removes trailing
spaces and interpunction
- multiple successive spaces are removed outside of [code] (and thus
don't count towards the length of the message)
The function should be mostly equivalent in regards to all other things,
ignoring a few minor border cases that weren't documented in the first
place. The URL regex (and the idea of a global regex) came from bpaste:
http://g.blicky.net/bpaste.git/commit/?id=ac7b16d0ec0f195d00a0a79698f67c3010e8cf7d
|
|
The release filters are now pretty much complete. Save, perhaps, for
some improved styling and grouping in the filter selector; but I'm too
lazy for that at the moment.
|
|
Surprisingly enough, the SQL queries are still quite fast even when
matching on the animation columns.
And thanks to the new filter system, adding this filter was incredibly
easy.
|
|
Primary reason for this change is because Algorithm::Diff::Fast isn't
all that fast for character-level diffs. :-/
|
|
This greatly reduces the size of the Javascript file. The compressed
size has been reduced with about 9kB, and is now a total of 14kB for
en.js. A nice property of this is that more translations can be added
without increasing the JS size.
While I was at it, I made jsgen.pl also replace mt() function calls in
cases where an exact TL string was requested without any additional
arguments and/or formatting codes. This helped reduce the compressed
size by about 1kB.
My aim is to keep *all* the JS code of VNDB smaller than the jQuery core
library, as a general "fuck you" towards users of large and bloated JS
libraries. We must keep the VNDB page loading times lower than that of
other sites, after all!
|
|
This effectively reverts 799c9e44b1a1a7776609273733f67887a74e33bf.
|
|
There's no validation of the filter string yet, and somehow I don't feel
like adding that; it's a lot of code and there's nothing to protect -
the values are inserted using parameters into a SELECT query, the worst
thing that could happen is the user receiving a 500.
Also, I've started using the perl '//=' operator, which was added in
5.10. This removes support for older perls.
|
|
This makes deleting user accounts less error prone.
It also seems I forgot to git add update_2.14.sql in an earlier commit,
sorry about that.
|
|
This effectively removes compatibility with all PostgreSQL versions
below 9.0.
The use of the WHEN clause has two major advantages:
1. Performance: Trigger functions aren't executed when they don't need to.
2. Easier and more general trigger functions; as some of the logic has
been placed in the trigger definitions now.
|
|
Back from 180s to ~5 or ~6 seconds. It used to be quite fast on
PostgreSQL 8.4, but somehow the planner failed to generate a proper
execution plan for that query after the upgrade. This query is fast 9.0.
|
|
TODO: add links to these feeds from the site
|
|
|
|
This is a very old bug. Never fixed it before because I couldn't think
of a clean/easy solution and it wasn't important to waste my time on.
|
|
A nice expanded view. It also happens to be faster than the old view in
terms of SQL queries. (In most cases at least)
Can be improved a little more by:
- Adding an 'expand/collapse' feature to list only the VNs
- Adding a column indicating the role of the producer (dev/pub)
|
|
This module is cleaner, faster and has less dependencies.
(didn't exist yet at the time I first implemented the revision diffs)
|
|
This is the first part. The flag is stored in the database, can be
edited through the usual VN edit form, and is displayed in the diff
viewer.
Things to do to make this feature fully functional:
- display "official" status on VN page at the relation listing
- update relation graphs to display unofficial relations differently
- update guidelines
|
|
Not very useful, anyway.
|
|
Just a simple question.
|
|
The code is a bit more complicated now, and it's not a lot faster, but
at least this helps a bit.
|
|
Similar to ab64b573846da39622b8d430b079d7e8806a35d3, but with a few more
constraints as dbVNGet() is a more generic function. This and the other
commit greatly improve the page generation time of the homepage. From
~250ms to ~110ms in my tests.
|
|
By rewriting the query and using the trick documented here:
http://blog.rhodiumtoad.org.uk/2009/03/08/selecting-random-rows-from-a-table/
Can be further optimized by putting an index on vn_screenshots.scr
|
|
Really need a cleaner solution for that. PostgreSQL actually provides a
better solution, need to change to that.
|
|
Also fixes a cross-site request forgery vulnerability. Not as strong as
the others but it's not very crucial anyway.
|
|
|
|
|
|
And clean up the alias field before it gets inserted into the DB.
Does not provide any feedback to the user, let's just hope our users are
clever enough to figure out what happened.
|
|
|
|
|
|
This makes jsgen.pl a bit easier to maintain, as there's not one
reliable source to get the keys from (namely, the JS code itself).
Also cleaned up the l10n() function in jsgen.pl to be more readable.
I had expected the new .js file to be smaller because this trick may
remove some keys that were previously present but unused. Unfortunately
it seems the file only grew a bit larger and compression seems to be
less effective now. No idea why this happened. :-(
|
|
This replaces the "cookie_auth" setting, and applies to all cookies in
use by VNDB.
|
|
And made sure the dimensions are truncated in VNDBUtil::imgsize().
Setting the width/height attributes makes sure that the browser can
reserve space for the image when it hasn't been loaded yet, which
prevents the overall page layout from changing while the images are
loading. (which is annoying if your connection isn't all that fast)
|
|
Was growing too large and isn't really necessary anymore, now that VNDB
is indexed quite well in most search engines.
|
|
And changed the order a bit, as suggested by ImmLff.
|
|
|
|
|
|
|
|
|
|
Like as with Steins;Gate, where the year isn't known.
|
|
|
|
|
|
|
|
|
|
|
