Adding custom attributes to comments

Searched the forum but saw nothing addressing data extensibility.

Could someone point me to the 'proper' jamroom approach one should use to add persistent attributes to an item? In my case, I need to add metadata to each Comment. (An example of metadata would be a 'child count'.)

Essentially I would capture the information when a comment is created, persist it (key:value) and then render it as HTML attributes on each comment.

( Background: this is to implement an efficient threaded tree of comments to support new user functionality. )


--
TiG
updated by @tig: 11/16/17 05:16:50AM

Threading is already an option of the jrComments module.
ACP -> MODULES -> ITEM FEATURES -> COMMENTS -> GLOBAL CONFIG -> LIST OPTIONS -> ENABLE THREADING

In answer to the question though: You can add anything you like to any items datastore, but it must be prefixed with the modules prefix. For the comments module, that's 'comment_'.

You can add any extra fields you like to an item, they're just stored as KEY : VALUE pairs that become available in the templates along with the rest of the items info.

Thanks. I am using jrComments threading ... just going beyond what is implemented.

I appreciate the guidance on persistence. Always seek to follow the natural grain of the design so your feedback is greatly appreciated.


--
TiG

the jrTags module might be useful to look at, it injects stuff into other modules datastores. It will save the tags for an audio file of jrAudio directly to that modules datastore.

useful for reference maybe.

@michael - one of my (safety) concerns is making changes to arbitrary datastores in other modules. It would be quite convenient (for me) to store the child count for level 0 comments (i.e. the number of level-0 comments) in the item referenced by the comment_item_id in the root module (comment_module). No concern if the comment_module is jrBlog, but it could (theoretically) be anything. Seems there would be the potential for name collisions, denied access, etc. If I stay within jrComment the conditions are in my own local control.

Given these unknowns (and realizing that my unfamiliarity with jamroom will lead to wrong-headed overly-conservative ideas on my part) I have focused on a solution that keeps all data changes within the jrComments module.

But I would welcome your opinion on this. I need to store a node count (and a hierarchic node id such as x.y.z) in each comment. The node count holds the current number of child nodes. All is cool except I have no place to store the node count for level 0 items in the jrComments module. Would it be a safe practice IYO to inject data into the comment_item_id item without concern for what the comment_module it might be in? My approach is to, in effect, carve out an area to persist metadata within jrComments (with node count -number of level0 items- being the only metadata at the moment).


--
TiG

I usually play round with concepts to find one that works in code, then start thinking about how efficient its going to be once I have something that works.

My first thought for "How do I retrieve the number of children this comment has" is caching. Run a query to search whenever the parent comment is shown to get the number of children, then store that in the cache. When a new comment is added as a child, reset the cache for that parent.

WHY: because it means the count will always be correct and I don't need to think about things like comments being deleted and updating counts.

I can see that you might want to run queries against that number though, so if you're needing to get "Get me all the parent nodes who have more than X children" then running a sub-query for this might be slow, so storing the info might be better. In which case I would probably look to storing it on the comment itself 'comment_children_nodes' as a number. That would make it easy to look up in the datastore, you'd just need to keep that up-to-date each time a comment was added.

If that's the way you go, put a listener into the 'integrity check' that re-counts the counts when the integrity check is run so that if the counts do get out of sync with the actual comment count there is a way to get them back to correct.

Docs: "Events and Listeners"
https://www.jamroom.net/the-jamroom-network/documentation/jamroom-developers-guide/1011/events-and-listeners

maybe the 'repair_module' listener:

@michael - The intended behavior is to leave gaps in numbering to show where a comment is deleted. In result, the child count need only be incremented - the gaps are what we want. But thanks for your thoughts.

My concern is really getting the number of level-0 comments so that I know what high level number the next level-0 comment should be. So assuming we have 1, 1.1, 1.2, 1.2.1, 1.2.2, ... I need to have an efficient method to know that the next level-0 comment will be 2 (with future children of 2.1, 2.2, ...). I can always issue a query of course, but that is what I am trying to avoid. The ideal solution is to store the current number of level-0 children somewhere in jrComments.

Anyway, it was not my intent to consume your time on this so thank you again for your thoughts.


--
TiG

OH! if thats the intention then I would do it differently.

Listen for the delete comment action and don't delete it. just remove the contents and leave the comment there. "this comment has been deleted"

Add a flag to it 'comment_deleted' = 1. (and maybe move it to a different holding profile too in-case the profile gets deleted.)

@michael - Thanks for the advice.


--
TiG