Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
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.
|
|
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 >.>)
|
|
Also requested several times before.
|
|
Has been requested quite often, now finally implemented.
|
|
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.
|
|
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
|
|
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
|
|
Which may also be useful for other scripts.
|
|
This adds a new column to the vn table: c_search, which holds the
normalized titles for speedy search results using LIKE.
Also split some functions from VNDB::Func that didn't require YAWF into
a VNDBUtil module, so Multi can also make use of them. The normalization
functions are the same for Multi and VNDB, after all.
The API and Multi::IRC still use the old search, these should be updated
as well.
|
|
Conflicts:
data/lang.txt
|
|
And changed vn.c_languages to an array type while I was at it. This
required some changes in the Perl code, and I found a bug in DBD::Pg
while I was at it:
https://rt.cpan.org/Ticket/Display.html?id=54224
Luckily, there's an easy workaround for that.
|
|
This is implemented by adding ihid (item hidden) and ilock (item
locked) columns to the changes table,
The (vn|release|producer).(hidden|locked) columns now work as a
cache, refering to the changes.(ihid|ilock) columns with
changes.id = (vn|release|producer).latest.
The cached columns are updated automatically each time a new revision is
inserted.
This is a pretty large change, bugs are quite likely.
|
|
|
|
This will make it easier to do automated edits, either from cron jobs,
Multi, update scripts, or from within SQL triggers.
So far only the VN related functions have been defined/updated, trying
to edit/add releases or producers will not work at the moment.
The functions for editing or adding a new database entry have been
merged, as the procedure is rather similar.
util/dump.sql will be updated later on.
|
|
This column was used to differentiate between automated edits and user
edits, but that later changed to checking for changes.requester = 1.
The column has since never really been used, and due to a bug introduced
in VNDB 2.0, it has never been updated, either. Meaning it's not even
accurate for any database changes made after december 2008...
|
|
This removes the need for the dbVNCache() function in perl.
|
|
And also changed the way the item_table.latest column was updated: it is
now only updated after the revision insert has completed, making it
easier to write trigger functions in SQL.
|
|
This drastically improves the performance of the search-VN-tag-filter
feature, and it seems PostgreSQL can use the index even when only
filtering results by the tag column.
|
|
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.
|
|
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
|
|
Was a good idea after all...
|
|
This adds about 100ms (sometimes more) to the page generation time of VN
pages... maybe I should cache the ratings after all.
|
|
It's even realtime! To my surprise this calculation isn't very heavy, or
PostgreSQL is just extremely fast. The GetVN query on /v/all takes 100ms
in the worst case (instead of the usual 30-60ms). Can always cache this
later on.
|
|
As the same table can easily be used to store producer relation graphs
as well.
|
|
This is a very important column in a very important table, I hope I
didn't forget to update a piece of code somewhere...
|
|
This is a workaround for a bug in DBD::Pg:
http://rt.cpan.org/Public/Bug/Display.html?id=40199
Also added a charset to the content type header of the relation graph
pages, though this wasn't really necessary for my Firefox to work.
|
|
The graphs are now stored in the DB in SVG format, the static/rg/
directory can be removed (not used anymore).
SVG data is stored using the xml data type, so now I can say for
sure you'd need at least PostgreSQL 8.3.
This feature still needs some tweaking, though. Current state isn't
perfect.
|
|
That was the last one. I hope I haven't forgotten to update anything.
|
|
Anything fetched from the DB to Perl should be converted to a UNIX
timestamp, and everything that goes from Perl to the DB should be
converted from a UNIX timestamp to a timestamptz data type.
Also, when creating a session, don't rely on the fact that the
expiration default happens to be the same as the cookie expiration time
calculated in Perl. It's cleaner to calculate the date at one place and
then use that everywhere else.
|
|
|
|
There were only two states, processed and unprocessed, so simply
using a boolean column with correct naming is more clarifying.
|
|
This is a lot less error-prone than doing it from Perl.
<3 PostgreSQL
|
|
|
|
|
|
TODO:
- spoiler settings?
- auto-complete tag names
- exclude filter
- Improved UI? current location isn't very intuitive
- Improve previous tag browser to make use of the VN search?
|
|
+ Set 2.4 date in ChangeLog
|
|
The tags work fine already. I'll keep the categories on the VN pages
and in the history for now, though.
|
|
|
|
|
|
|
|
|
|
Fixes:
For newly added vns popularity status is something like
Ranked #1709 out of 1692 with a score of 0.00.
|
|
|
|
revisions
It's a pretty tricky bug, so finding a proper fix took a while...
|
|
|
|
The following query should be run periodically to update the rankings:
SELECT update_vnpopularity();
I'll fix Multi::Maintenance to do this automatically.
|
|
|