| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Everything has now finally been converted to use the PgSQL LISTEN/NOTIFY
feature. This commit removes the last Tie::ShareLite dependency.
|
|
|
|
To be consistent with users.passwd - hashes are stored in binary. All
conversion from/to hex is done in the DB layer.
|
|
The graph looks even worse now, oh well.
|
|
That syntax error was partly 3dB's fault, and partly my fault for
changing too much in that merge, heh.
|
|
Conflicts:
util/dump.sql
util/updates/update_2.6.sql
Also updated ChangeLog and made some tiny style changes.
|
|
-- Updated SQL files to reflect column type change.
-- Subroutine dbSessionAdd rewritten to accept an expiration
timestap as an optional third argument.
|
|
This commit is tested to work.
|
|
-- Removed "ON UPDATE" from sessions.uid column FK
-- Fixed dbSessionCheck to work as described
-- Merged DB/Sessions.pm into DB/Users.pm
|
|
Added a new DB library for handling sessions.
New update SQL file for database changes.
Added a line to the global config file to set a global salt. It is separate
from the cookie_key because it is much more important that it not be changed.
|
|
This finishes the new relation graph generator, as it'll now regenerate
graphs as soon as is needed.
This obsletes the VNDB::Util::Misc::vnCacheUpdate() function, this
functionality is provided by triggers within PostgreSQL.
The update_vncache(0) procedure is now significantly slower due to the
trigger on the vn table. It'd be a good idea to rewrite this procedure
by using triggers and conditional updates, to drastically lower the number
of rows that need to be updated.
|
|
Not that the output makes much sense now, but at least it's (mostly)
correct.
|
|
Only allowing the deferred state on a select few foreign keys would
detect problems in an earlier stage (rather than waiting for a commit to
happen), and guarantees that some things are inserted before others,
which in turn eases the writing of trigger functions.
|
|
|
|
This finished the rewrite of Multi::Image and everything surrounding it.
|
|
There were only two states, processed and unprocessed, so simply
using a boolean column with correct naming is more clarifying.
|
|
Yay! Another weird shared-memory-command optimized away. And the image
resizer reacts a lot faster now. Noticably, even.
|
|
The notify is called from a trigger function, which is called on any
UPDATE or INSERT INTO query of which the lastfetch column is NULL.
This guarantees that anime info in the DB will always be updated, no
matter how its inserted.
|
|
This is a lot less error-prone than doing it from Perl.
<3 PostgreSQL
|
|
Removed most NOT NULL constraints, and converted lastfetch to a
timestamp data type.
The site has been updated to handle this, but Multi::Anime won't work.
|
|
Started on multi.pl and Multi::Core, the main differences:
- Uses POE::Component::Pg now (get it from http://g.blicky.net/poco-pg.git/)
- Doesn't use shared memory anymore
- No 'commands' anymore, every session has to handle its own events
(communication goes either through POE itself, or the PostgreSQL DB)
- No weird Cron stuff anymore
All other Multi modules will have to be updated/rewritten to reflect
these changes. None of them will work at the moment.
|
|
|
|
|
|
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.
|
|
+ Set 2.4 date in ChangeLog
|
|
I really need to write an abstraction layer within PgSQL to make inserting
new revisions using plain SQL easier.
|
|
|
|
|
|
TODO:
- update d3
- filters on /r
|
|
TODO: filter on /r
|
|
TODO:
- Update d3
- Add filter to /r
|
|
The bayesian ranking algorithm isn't exactly meant to be used to
differentiate between absolute values, so do a pre-check on AVG(vote)
before considering a VN in the rating.
I've also played around with using plain old averages as score, but I'd
say the ordering is a lot better with the bayesian ranking, the displayed
score is just slightly more confusing.
|
|
Use a user's highest vote on a child tag in the calculation of the
rating of a parent, rather than the average.
|
|
Fixed major performance bug caused by referencing the wrong table, moved
all intermediate views to tag_vn_calc() as temporary views (similar to
update_vnpopularity()) and renamed tags_vn_stored to tags_vn_bayesian.
|
|
|
|
Conflicts:
lib/VNDB/DB/Discussions.pm
util/updates/update_2.3.sql
|
|
|
|
Which is a more accurate description, and doesn't confuse with the
tagging system.
Note than even all internal uses of the word 'tag' have been replaced,
as I'm not a huge fan of different terminology in the code and UI. This
update might break some things related to the discussion board.
|
|
|
|
|
|
Updated hourly by Multi.
May want to look for a better way to update this cache, because I'm
afraid the current tags_vn_calc() is going to perform very badly on
larger databases.
|
|
|
|
|
|
|
|
...taking into account the votes on child tags and one user
voting on multiple child tags.
Doing this realtime is slow... very slow. Tried playing around
with storing the ratings in a normal table for caching, but don't
have enough data to do proper benchmarks and determine the fastest
method yet.
|
|
Consistent with all other aliases field
|
|
But it already starts to look like something that might work.
|
|
|
|
Mostly playing around with the possibilities,
tag page layout & database scheme are far from final
|
|
|
