Age | Commit message (Collapse) | Author | Files | Lines |
|
In the special case where the releases of multiple VNs are requested,
and those VNs have releases in common, dbReleaseGet() would return those
releases multiple times. Using a JOIN in order to filter rows isn't safe
if the join condition isn't unique - so use an "id IN(SELECT ..)" filter
instead.
(I found this while editing c15068 and noticing that some releases were
listed twice in the edit form. Editing that entry without manually
removing those duplicates would trigger an internal server error due to
duplicate relations)
|
|
As discussed in https://vndb.org/t10665
|
|
|
|
Fixes https://vndb.org/t950.210
|
|
|
|
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.
|
|
Fixes http://vndb.org/t5136
|
|
|
|
|
|
This is under the assumption that earlier releases are added earlier,
even when they're released on the same date. (E.g. in the case of v9678)
|
|
|
|
|
|
|
|
Still somewhat quircky, but it works.
|
|
Makes more sense this way.
|
|
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.
|
|
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 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.
|
|
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 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.
|
|
Also added a little sanity checking on the edit_(vn|release) table,
and added a default value for releases_rev.released.
|
|
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.
|
|
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.
|
|
|
|
This is a very important column in a very important table, I hope I
didn't forget to update a piece of code somewhere...
|
|
They aren't displayed on the site yet, though.
|
|
|
|
That was the last one. I hope I haven't forgotten to update anything.
|
|
The 'language' column in releases_rev has been replaced with a
releases_lang table. As this is quite a big change, there may still
be bugs floating around somewhere.
|
|
This fixes an internal server error when searching on a number in the release browser.
|
|
|
|
|
|
|
|
|
|
|
|
TODO:
- update d3
- filters on /r
|
|
TODO: filter on /r
|
|
TODO:
- Update d3
- Add filter to /r
|
|
|
|
|
|
|
|
|
|
This browser is still -very- basic, more filters and options will
be added later.
|
|
Using the same method as 203509ffd8fc2fbbd76129d701a6c20110f6050d
|
|
|