Add karma for comments

[mekarpeles]

Prevent gaming of system by deleting / editing posts - on disable, karma

[xraymemory]

In doing so, ought we to make a db model for the comments? Or could we get away with changing the comments from a list to a dict so we can store the votes for the individual comments?

[mekarpeles]

The whole db will have be reworked at some point, I am not completely sure lazydb will scale to even hundreds of thousands of records.

At first glance, I think the most effective strategy will be to store all the comments within the paper data structure, as is being done, and then (for purposes of displaying / rendering the comments) store the relationships / links between the comment entities in a hash within each paper. We know that comments only exist within the scope of a paper, so I think it makes sense to keep the comments within the paper data structure for now. This reduces the complexity of the problem in that we don't have a search space of 'every' comment and its much easier to re-compute scoring for a single paper's comments. Calculation becomes a simple BFS traversal (or comparable tree search) to calculate top level nodes as well as all subsequent children.

Some important use cases / considerations are:
a) quickly retrieving a comment by id
b) calculating (or updating, if score is cached) a comment's score

Questions:
For our implementation...
a) Do posters get karma points for any comment?
b) Do commenters get karma points for any comment contributed to their reply thread?

Data Structure

$ pwd
~/openjournal/openjournal
$ python
>>> from lazydb import db
>>> db = Db('db/openjournal')
>>> db.get('papers')[0]['comments']
{'cid': 6,
 'comment': u'<p>http://google.com test</p>',
 'enabled': True,
 'pid': 0,
 'pcid': None, # parent comment-id (new!)
 'time': 'Tue Feb 12 06:54:12 2013',
 'username': u'mek',
 'votes': 0},
>>> db.get('papers')[0]['comment-heirarchy']
{3: [12, 1],
 4: [],
 5: [8],
 ...
}

Scoring & Karma

Properties:

• a comment can only have 1 parent
• a comment can have n different children

Steps:

Summary: We traverse the leaf node's pcid (parent comment id) upwards towards the root, accumulating scores by 1 up the branch until the parent node (i.e. the comment thread original poster) is reached.

The following are the steps to consider when a new comment is posted (which may be a reply)
a) Load all the comments for a paper into memory given pid (i.e. paper id)
b) if the comment is a 'reply' (i.e. a comment has a pcid - parent comment id) then:

• Iteratively traverse each node impacted by this new comment. Namely, the set of impacted nodes are all nodes along the path from the leaf node to the parent node, denoted by the topmost node having no pcid (i.e. pcid == None).

Code:

# assuming pid defined / provided
comment = { ... } # leaf node comment
papers = db.get('papers')
paper = papers[pid]
comments = paper['comments']
score = 0
""" we have to check versus the value None because 0 can be a valid pcid
unless we redesign our system to explicitly enforce a constraint of nonzero ids.
this would also be messy since some of our algos use list indexes to retrieve content
rather than an explicity primary key. Again, we could solve this by just subtracting 1 from
the primary key to get its location / index.
"""
while comment['pcid'] is not None: 
    score += 1        
    pcid = comment['pcid']
    papers[pid]['comments'] += score# careful for case where comment's score is not int (should default to 0)
    comment = comments[pcid]
db.put('papers', papers) 

Optimization

We may consider cacheing scores and then recalculating/updating scores for posts

Display Comments

We'll need to update our algorithm for displaying comments. Luckily, our comments will always be a tree (and not a graphic with cycles) so it shouldn't be too bad.