Age | Commit message (Collapse) | Author | Files | Lines |
|
Reverted back to the old behaviour.
|
|
|
|
|
|
|
|
And renamed notify_dbedit to notify_nodbedit, since the default is to
provide a notify on a database edit.
Also fixed a few bugs along the way.
|
|
In the users_prefs table, the default value should evaluate to 'false'
in Perl, so show_list had to be inverted to hide_list.
|
|
|
|
Will convert the other preferences later.
|
|
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.
|
|
Can only filter on one option. If there are more things to filter on it
would make sense to use the filter selector, but for now this will do.
|
|
The interface to set this could be more dynamic, since it'll be a lot of
work to set different notes for each VN. But oh well, let's first see
how many people will use this feature.
|
|
|
|
|
|
|
|
|
|
I'm sure I broke all vnlist/rlist-related features on the rest of the
site since I modified the DB abstractions. But these will all have to
be updated/rewritten anyway.
|
|
This can be seen as a partial revert of
0a4f97f0186d6941a4cab2e3bd05201f1fed1441.
I used to think using NULL for special values is more "correct" in
database terms. But in the end I guess I should be aiming for whatever
solution is easier. Both are "correct" in a sense anyway.
|
|
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.
|
|
|
|
I'm surprised I haven't been able to find a combination of filters that
would generate an SQL query that would run more than 300ms or so.
PostgreSQL is amazing!
|
|
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.
|
|
The release filters are now pretty much complete. Save, perhaps, for
some improved styling and grouping in the filter selector; but I'm too
lazy for that at the moment.
|
|
Surprisingly enough, the SQL queries are still quite fast even when
matching on the animation columns.
And thanks to the new filter system, adding this filter was incredibly
easy.
|
|
There's no validation of the filter string yet, and somehow I don't feel
like adding that; it's a lot of code and there's nothing to protect -
the values are inserted using parameters into a SELECT query, the worst
thing that could happen is the user receiving a 500.
Also, I've started using the perl '//=' operator, which was added in
5.10. This removes support for older perls.
|
|
This makes deleting user accounts less error prone.
It also seems I forgot to git add update_2.14.sql in an earlier commit,
sorry about that.
|
|
I added this clause to slightly speed up the SQL query at producer
pages, but it turns out to slow down release search queries by a factor
100.
|
|
It's an awesome feature now. :-)
|
|
A nice expanded view. It also happens to be faster than the old view in
terms of SQL queries. (In most cases at least)
Can be improved a little more by:
- Adding an 'expand/collapse' feature to list only the VNs
- Adding a column indicating the role of the producer (dev/pub)
|
|
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
|
|
The code is a bit more complicated now, and it's not a lot faster, but
at least this helps a bit.
|
|
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
|
|
Really need a cleaner solution for that. PostgreSQL actually provides a
better solution, need to change to that.
|
|
Conflicts:
lib/VNDB/DB/VN.pm
lib/VNDB/Func.pm
|
|
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.
|
|
Crawlers would often find such pages, and the query would often take
more than a second to finish, in some extreme cases even 10 seconds.
This fix converts an intermediate result into an array, forcing the
query planner to evaluate the subquery first, resulting in a far more
optimal query plan.
|
|
1. Don't try to normalize the GTIN code in the releases form when it's 0
2. Don't try to gtintype() *every* number in the search
|
|
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...
|
|
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.
|
|
These aren't likely to change anyway, and things will become less easy
to display when other types of notifications are added.
|
|
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...
|