| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
So that the /util/sql/ files are in sync with the actual DB again.
|
|
Conflicts:
lib/VNDB/DB/VN.pm
lib/VNDB/Handler/VNPage.pm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Moves staff<->vn linking form to the main VN edit form
- Fixes a bug with linking staff aliases to VNs
- Adds staff changes to the VN revisions
- And some misc. improvements
|
|
|
|
Used to link to a visual-novels.net review or something. Links have been
hidden and dead since ages. No need to keep the column around.
|
|
I increased the N parameter to approximate about 500ms to generate the
hash. This is quite a paranoid setting for a website, but login attempts
are throttled so there's not much of a DoS factor. (Alright, password
changing feature isn't throttled so the DoS factor still exists. But
really, there's some pages with longer page generation times anyway.)
I did lower the size of the salt a bit (Crypt::ScryptKDF uses 256 bits
by default), because 64 bits of randomness should have low enough chance
of collision with only ~100k users (even with a million users,
seriously).
|
|
It doesn't make a whole lot to separate the hashed password and the salt
from each other, you need both to do anything with them, and from the
database perspective they're both completely opaque strings only usable
for direct comparison with other hashed strings.
This change is mostly as preparation for switching to a proper key
derivation function (sha256 isn't...) and to add support for longer
and/or binary salt.
Because the passwd field now needs to be interpreted in Perl, it's being
passed around as a binary string rather than a hex-encoded value.
API login is broken in this commit. I'll get to that.
|
|
I believe I didn't do this conversion earlier (back when I converted the
language types) because PostgreSQL didn't support dynamically adding new
values to an existing enum back then, and modifying an enum was a huge
pain. Recent versions do support this, so there's no reason to keep it
as a string.
...I just felt like adding some churn to the code base.
|
|
Easier to work with in custom queries.
|
|
Suggested by Hinoe, quoting his reasoning:
In popularity rankings, change the normalization from
"sqrt(LowerVoteCount)" == "LowerVoteCount^0.5" to something that grows
somewhat more slowly.
Details: Natural logarithm itself (ln(LowerVoteCount+1)) is too slow;
at the current VN count (15403), it returns 9.64; however, sqrt(15402)
is just above 124.1, which I feel is already too high. After
experimenting with the exponents a bit, I decided that the best point
likely lies between 0.3, which returns a bit above 18.0, and 0.4,
which returns a bit above 47.3. Thus, I suggest that the new function
be LowerVoteCount^0.36788; the exponent is a 5-digit approximation of
e^-1, just because it's a nice number in the specified area and works
well, returning circa 34.7.
|
|
|
|
|
|
|
|
All the async stuff isn't necessary now that images are processed
synchronously.
|
|
TODO: Get rid of the 'processing' flag and all the async loading of
screenshot data in the screenshot uploader.
|
|
|
|
I used to do this to avoid loading Image::Magick in each TUWF process,
decreasing memory usage, and lowering the blocking time by avoiding too
much processing. Memory isn't much of a problem nowadays, and processing
images is fast enough, too, so this complexity isn't necessary anymore.
(Character images and screenshots pending)
|
|
|
|
The ordering unfortunately matters for some tables, due to the edit_*
stored procedures relying on it. :-(
|
|
|
|
|
|
|
|
And added an update_2.23.sql file which now also includes the previously
added indices. Currently, this update file can be run as often as you
want, it doesn't make any noticable changes when you run it on a
database that has already been updated. (i.e. I can update the main site
without a new release)
|
|
This brings the average page generation time for VN pages down from
~170ms to ~90ms (when measured over a period of a few hours).
I haven't put this in an update script, if you want to take advantage of
these indices make sure to manually add them yourself.
|
|
Required in order to search for hidden entries (obviously :P)
|
|
|
|
|
|
This is far more flexible.
|
|
|
|
|
|
|
|
|
|
|
|
The field isn't used yet.
|
|
|
|
|
|
|
|
I'll have to optimize the updating of traits_chars as soon as I have
some data to test with.
Also renamed tags.c_vns to c_items, to have it share the same name as
traits.c_items. This makes it a lot easier to re-use code for both tags
and traits, such as what I did with dbTagTree/dbTraitTree -> dbTTTree
and the childtags() and parenttags() functions.
|
|
It's more like a cache, and has some unintuitive problems when a trait
is applied to multiple top-level traits. But this'll do the trick
anyway.
|
|
|
|
|
|
|
|
|
|
The Perl code and SQL-revisioning code only handles the name, original,
alias and desc fields at the moment. There is a basic /i+ and /i+.+ page
for testing, which should have all the functionality required for the
revisioning framework.
|
