| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Yay!
There are no more request handlers in the VNDB::* namespace and no more
Javascript in data/js/. This cleans up a lot of old legacy code that
wasn't fun to maintain.
|
|
|
|
This fixes the issue of tag votes getting deleted when a user account is
deleted, despite these votes being part of the kept "database
contributions" mentioned in the privacy policy.
|
|
This also changes the voting interface a little bit:
- Spoiler options are a bit more concise
- Mouse-over a button indicates what it does
- The -1 and -2 options are not available anymore
- Downvoted tags are hidden by default
- Moderators can now vote-and-overrule in a single go
|
|
Only place where this isn't applied (yet?): Sorting user lists still
goes by the old username and board names don't use the new unicode
names.
I have to say, I quite like the sql_user() and user_() pattern. It's not
without problems when applied to everything, but it's good enough for
several use cases.
|
|
This has some limitations:
- tags.c_items is not updated, so that may be out of sync.
(The UPDATE takes about 400ms, so doing that more regularly from
Multi::Maintenance should be a viable option)
- When the hidden flag of a VN is changed, the tags will also be out of
sync.
- I don't see a way to do fast incremental updates when tag entries
themselves are changed, e.g. to handle changes in the tag tree or
searchable flag
|
|
|
|
The previous code would assume that these tags did not have any votes,
but that assumption doesn't necessarily hold anymore.
|
|
As discussed in https://vndb.org/t12507
TODO:
- Same conversion for traits
- Re-add mod ability to delete all votes for a particular tag?
|
|
https://vndb.org/t11296.3
(And I forgot to add update_20180929.sql in the previous commit)
|
|
This is a generalization of the search improvements made in
7da2edeaa0f6cf7794f4f8f68960497dc1be893c and
92235222dba4e5d0c7713d53ef12e0f10e371b83
And has been applied to the dropdown searches for producers, staff, tags
and traits.
For all those searches, exact matches are listed first, followed by
prefix matches, and then substring matches. Relevance is currently only
based on the primary name/title and ignores aliases (except for staff).
This is fixable, but not trivial, and I'm not sure it's all that useful.
|
|
Reduces page load time of the trait index from 200ms to 20ms. Also
provides a slight improvement for other tag/trait tree views.
|
|
This basically makes VNDB browsable again, but editing entries is still
broken.
I split off the get-old-revision functionality from the db*Get() methods
into db*GetRev(). This split makes sense even with the old SQL schema:
db*Get() had to special-case some joins/filters when fetching an older
revision, and none of the other filters would work in that case. This
split does cause some code duplication in that all db*GetRev() methods
look very much alike, and that the columns they fetch is almost
identical to the db*Get() methods. Not sure yet how to avoid the
duplication elegantly.
I didn't do a whole lot of query optimization yet (most issues require
extra indices, I'll investigate later which indices will make a big
difference), but I did fix some low hanging fruit whenever I encountered
something.
I don't think I've worsened anything, performance-wise.
|
|
|
|
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.
|
|
|
|
|
|
Takes the burden out of our dear tag moderators to edit *all* tags
manually on the next update.
|
|
Not very useful at the moment, but will be used to improve several other
things.
|
|
This finalizes the moderation tag vote overrule. And Damnit, the logic
behind saving the tags to the database isn't fun, I hope I haven't made
any mistakes there.
|
|
This is the second step in adding support for overruling tag votes by
moderators.
This required a different approach to calculating the score in
dbTagStats(). For some reason this approach turns out to be slightly
faster as well...
|
|
This is the first step in adding support for overruling tag votes by
moderators.
Also removed some unused options from dbTagStats(); the
tag-vote-stats-by-user pages have been removed in the previous VNDB
update, which was the only page using these additional options.
|
|
This makes the UI slightly uglier and less intuitive. I'll see if I can
find a way around that. This update is required for the permanent
browsing filters to be fast and reliable.
|
|
Still need to add some links to the browser to parts of the site.
|
|
Currently unused, but this will be useful in the future.
dbTagLinkEdit() is now a lot more complex, since the last modification
date will be incorrect for unmodified tag links when we simply delete
and re-insert all related links like the old function did.
|
|
|
|
It should work perfectly now...
|
|
The return value of dbTagTree() is also somewhat easier to work with.
|
|
The ORDER BY was previously specified using an 'order' argument, which
would then be directly inserted into the query. The new method is the
same as what I used for the public API: two 'sort' and 'reverse'
arguments. This should be less error-prone and more readable.
This changes quite a lot of code, so I hope I haven't forgotten to
update something along the way.
|
|
With this method I managed to reuse the VN list table code for the lists
on both the VN browser and the tag pages. And optimized away the
dbTagVNs() function while I was at it (dbVNGet() is powerful enough)
|
|
For three reasons:
- Speed
tag_vn_calc() is now more than 10 times faster (granted, it could
have been a lot faster even with the bayesian rating, but whatever)
- Consistency with the tag scores displayed on the VN pages (which are
raw averages as well)
- It didn't always make sense
|
|
Ideally, all tag relations should be removed when hiding a VN, but that
would make hiding a destructive action, while currently it can still be
reverted easilily.
|
|
|
|
|
|
Fixed major performance bug caused by referencing the wrong table, moved
all intermediate views to tag_vn_calc() as temporary views (similar to
update_vnpopularity()) and renamed tags_vn_stored to tags_vn_bayesian.
|
|
|
|
|
|
|
|
There's no need for that anymore with the merge and state options
|
|
|
|
|
|
|
|
|
|
|
|
Couldn't think of anything more useful to display than simply all
tags without parents and a few of their subtags.
|
|
Updated hourly by Multi.
May want to look for a better way to update this cache, because I'm
afraid the current tags_vn_calc() is going to perform very badly on
larger databases.
|
|
|
|
|
|
Just prototyping, current implementation is too slow for actual use.
|
|
|
