Age | Commit message (Collapse) | Author | Files | Lines |
|
Also fixed a minor bug with no change notification being sent to Multi
when only the official flag has been changed.
|
|
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
|
|
Looks like I forgot to add vn.c_search
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
This makes sure that these also get forced reloaded on a version change.
|
|
Conflicts:
data/lang.txt
|
|
This one is also configurable, but mainly because I want to avoid
generating several thousands of notifications for a single action...
|
|
And added a settings window where you can disable this notification,
which is something you really want to do if you're an active
contributor...
|
|
Forgot to do this in the earlier commit.
|
|
|
|
As requested, http://vndb.org/t423
|
|
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 one's a lot faster.
|
|
Complex queries...
|
|
Nothing wrong with using the same name...
|
|
These aren't likely to change anyway, and things will become less easy
to display when other types of notifications are added.
|
|
62cb41c3b8780bffe5a8ea58a6a7b5053d9e1059
and
4895ea63323b94f0b128d6874be997a24d3a3b0d
were bad jokes, really... let's hope this permanently fixes the problem.
|
|
An expiration date doesn't make much sense if it's both not used and if
it can't be configured by the user, so just make this a timestamp to
indicate when the session has been added, which, while still not really
used, is more valuable.
|
|
If we're going to automatically remove older sessions, it would make
more sense to remove unused sessions, rather than old sessions that are
still in use. But we first need to keep track of when a session has last
been used to do so...
|
|
Setting the l10n cookie is now done from a separate url: /setlang
This makes the language determination code less complex, and makes sure
nobody links to pages that change the UI language without intending to.
(I've seen some links floating around with the l10n parameter included,
which is... bad)
|
|
The current setup should be able to handle all kinds of notifications,
though only PMs are implemented at this point. More to come.
|
|
Added a userid field in the skin config files, from which the credits
are loaded. Now I don't have to constantly update d7 for every language
when something changes in the skin files.
|
|
And updated skingen.pl and vndb.pl to make use of this abstraction.
|
|
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.
|
|
Simply re-using them by truncating the tables first is faster, and
requires less locking when performing batch edits in one transaction.
|
|
So that people with correctly configured browsers don't have to manually
choose their language of choice with the language switcher, and so that
most people will have one cookie less. (The 'l10n' cookie is removed if
it matches the Accept-Header language -- or the fallback)
More info @
http://www.w3.org/International/questions/qa-lang-priorities
|
|
The functions can now be edited without having to repeat them in the
update scripts. Just importing the func.sql file with \i will do the
trick.
|
|
|
|
Also added a little sanity checking on the edit_(vn|release) table,
and added a default value for releases_rev.released.
|
|
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.
|
|
To batch update, simply do a
SELECT update_vncache(id) FROM vn;
The function is now more readable as well.
|
|
This makes use of the change that the [vn|producers].latest columns are
now only updated after the entire revision has been inserted.
|
|
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 return value of dbTagTree() is also somewhat easier to work with.
|
|
This is more efficient, and doesn't require the tag_tree() or
tag_vn_childs() stored procedures. Does require PostgreSQL 8.4+
|
|
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
|
|
The previous statement was optimized for PostgreSQL 8.3 and took only about a
second, but after the update to 8.4 it took about 10 times longer due to a
different execution plan being generated. This slightly reworded statement
generates a more efficient plan on 8.4.
|
|
avg_rating should be the average rating of all VNs, not the global average
vote.
|
|
Sorting from least to most popular VN make sense now, you won't have to
wade through those entries without any vote at all.
|
|
They still have influence on the average number of votes per VN and the
overall average vote, but this isn't significant. (at least, not at the
moment)
|
|
Was a good idea 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.
|