Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
|
|
(interface is somewhat on the half-hearted side, but oh well)
|
|
And a "Don't forget to submit" text, and various important bugfixes,
and... geez, time for a coke with some cookies!
|
|
The usual: it's still pretty much useless and unfinished, will polish
up things later.
|
|
Consistent with all other aliases field
|
|
But it already starts to look like something that might work.
|
|
|
|
|
|
|
|
Mostly playing around with the possibilities,
tag page layout & database scheme are far from final
|