| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
The comment already suggested this:
I wonder whether it's better to just ask database for character list
instead of doing this manual group/sort
So yeah, let's just do that.
|
|
|
|
|
|
|
|
The styling of the staff info can be a bit awkward at times, but it
looks slightly better than a table, IMO. I didn't really know what to do
with the the seiyuu info - it wastes a lot of screen space in its
current implementation, but I can't think of anything better at the
moment.
|
|
|
|
|
|
|
|
- Merged polls table into threads table. Not much of a
storage/performance difference, and it's a bit simpler this way.
- Merged DB::Polls into DB::Discussions. Mainly because of the above
change in DB structure.
- Add option to remove an existing poll.
- Allow preview and recast to be changed without deleting the votes
- Set preview option by default. Because personal preferences. :)
- Minor form validation differences
|
|
|
|
|
|
Having the time display is quite useful. It does make the listings look
more cluttered, but meh.
|
|
|
|
|
|
|
|
|
|
|
|
While helpful, it's also rather dominant. We're not that desperate for
new contributes anymore.
|
|
Instead of the JS hack.
|
|
The possible values of the rel attribute is fixed, it's not supposed to
be a free-form field.
|
|
I'd have preferred to stick with XHTML 1.0, but unfortunately browsers
won't allow you to use modern Javascript APIs with an older doctype.
Note that most pages don't actually validate correctly as HTML5, I'm
relying on browsers to be lenient.
In either case, I'd like VNDB to stay valid XML (XHTML5, then), and
luckily that shouldn't be a problem.
|
|
DBD::Pg doesn't recognize the 'xml' data type as textual data, and thus
doesn't decode it for us. This fixes the display of non-ASCII
characters.
|
|
They had to be deleted from the database at some point, otherwise we
still have thousands of easily-cracked password hashes in the database.
Note that I could have opted to use scrypt on top of the sha256 hashes
so the passwords would remain secure without needing to reset
everything, but doing that after one year of switching to scrypt is
likely not worth it. Everyone who still actively uses his account has
already been converted to scrypt, everyone else should just reset their
password whevener they decide to come back.
|
|
|
|
|
|
|
|
|
|
'<> ANY' doesn't work that way. NOT EXISTS() is also pretty fast and
does what we want.
|
|
Turns out the anime data hasn't been updated in a few months. Oops.
|
|
Broken in bbe989de364ddc654bfc6385e22f1eaff23faad1. I forgot that floats
can't accurately represent some .5 numbers.
|
|
I don't know why I didn't apply this one before, I did make this change
when benchmarking the fulltext search queries and with the introduction
of the bb_tsvector() function this change pretty much always improves
performance.
|
|
The new database schema doesn't allow an alias to be removed when it is
still linked to a VN.
|
|
This broken filter would cause all staff info to be deleted from a VN
upon edit. Not so nice.
|
|
These indices provide a significant speed-up of /v+ and /u+ pages, and
improve some other stuff as well.
|
|
An index on threads_posts.date was necessary to speed up some very
common "recent posts" queries on both the homepage and the thread index.
Postgres thought that the same index could be used to speed up the
full-text search (because it's ordered by date, after all), but that
completely killed performance. That was solved with a bb_tsvector()
wrapper to tell the query planner that not using the full-text index is
incredibly show, which in turn improved the search performance beyond
what it was.
Many thread-related queries are still somewhat slow, but that seems to
be a limitation in the schema. I'll just keep monitoring to see if
that's worth fixing in the future.
Interestingly, dbThreadCount() needs to use a sequential scan, but it's
still remarkably fast.
|
|
Two main improvements:
- Filtering on (non)hidden items now doesn't join any of the item
tables, instead it looks up the latest revision from the changes table
itself, using the index on (type,itemid,rev). It's still not super
fast, but a pretty large improvement nonetheless.
- The item titles/names are obtained in a separate query. I tried to
modify the main query in various ways, but couldn't make it as fast as
I'd have liked.
I also removed the 'what' flag while I was at it, all uses of the method
request all information anyway.
|
|
That should be the last thing to convert to the new schema.
|
|
This changes quite a bit to the way the editing functions work. Because
these functions are very repetitive and it's easy to keep things out of
sync, I created a script to generate them automatically. I had to rename
a few function and table names for consistency to make this work.
Since database entries don't have a 'latest' column anymore, and since
the order in which tables are updated doesn't have to be fixed, I
dropped many of the SQL triggers and replaced them with a
edit_committed() function which is called from edit_*_commit() and
checks for stuff to be done.
Don't forget to run 'make' before importing the update script.
|
|
|
|
|
|
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.
|
|
Turns out that fetching whether or not you have unread notifications
(done on every pageview if you're logged in) was pretty slow. The index
speeds up both that query and the "my notifications" view.
The extra purge for old notifications for users with more than 500
notifications ensures that the index stays effective for the unread
notifications count. Otherwise it'll have to read half of the
notifications table anyway to check the 'unread' filter.
|
|
|
|
Adds slightly more strict validation and simplifies further processing.
|
|
|
|
No more need for extra json_encode/json_decode calls, and the
form_compare() function is more lenient w.r.t. integer/string
comparison.
This is the improvement I described in commit
ed86cfd12b0bed7352e2be525b8e63cb4d6d5448
|
|
This might have broken the screenshot uploader on some crappy browsers,
but it's much cleaner than the old iframe hack. The ability to upload
multiple files in one go is also very convenient.
|
|
|
