Duplicates and 'follow_unique' in jrdiscussion_follow_topic

This is a very specific question, but I am making use of the 'follow discussion' functionality and want to ensure I understand the semantics. The functionality seems to act as though (follow_topic_id,follow_user_id) is the unique key yet the table (by extension) shows duplicates for this pairing. From what I can tell, the duplicates occur if one is already following a discussion - each new comment posted on the discussion creates another record in the table. Thus following creates a record and each subsequent comment creates a record. Unfollowing deletes all records per (follow_topic_id, follow_user_id).

Question One: What purpose do the duplicate records serve?

Per this code, the follow_unique column is another factor:


Question Two: What function does follow_unique serve - especially given follow_created?

Again, I just want to ensure I understand this mechanism because my logic relies upon it to a degree.


--
TiG
updated by @tig: 02/22/18 06:24:01PM

From memory: There should only be one pair per topic and the state of the button being displayed toggles the state. So in a perfect world if the user is following the button shows them following, if the user is not following, the buttons shows them not following.

I think somewhere duplicates were slipping in ( maybe caching not showing the correct state of the button, not sure, vaguely remember something. ) and so the delete all records was added.

As for the follow_unique, I believe thats so that the correct follow can be deleted via things like an email link. if links like
.../.../.../remove_follow/user_id=1/topic_id=1 worked it could allow for someone who did not own that follow removing another person from the following list.

If you know steps that consistently add duplicates I can go look at the code again.

@Michael - the only process that consistently adds duplicates that I have found is as I noted. If a user clicks to follow a discussion that generates a record. Each comment the user makes on the followed discussion creates another record.

The odd thing about follow_unique is that the data content is simply a time value. It seems to simply be a uniqueness factor yet it is not clear how it is ever used.

Regardless, my question was simply due diligence. Follow does seem to work for my purposes. As long as I can conclude that a particular user is following a particular discussion (topic) by the presence of at least one (topic,user) pairing in the database then my logic will work.

In short my algorithm presumes: at least one pairing = following, no pairings = not-following

Thanks.


--
TiG

Checking this out - thanks.


--
Paul Asher - JR Developer and System Import Specialist

Hi Tig
Have fixed this up on your site.
The jr_jrdiscussion_follow_topic table unique index wasn't configured corrected. This is now done and all duplicate entries have been removed from the table. Also, the module code has been updated to use the table correctly.
See how it goes.
Note that if any of your users followed a topic during the few minutes whilst the table was being cleaned up, it may not have been stored, so they may need to 're-follow'.
Thanks
Paul


--
Paul Asher - JR Developer and System Import Specialist

@Paul

Thanks so much for doing that. Were your changes limited to jrDiscussion?

I would like to apply these changes to our alpha site so that my new module (ntTracker) works with what it will see in production. Thus I need to know what was changed. I presume I could simply copy jrDiscussion from production and upload it to the alpha site and run integrity check. Is this true? (Alpha is up to date with all updates as of today.)


--
TiG
updated by @tig: 11/20/17 03:06:42PM

you can use the ACP -> MODULES -> DEVELOPER -> DEVELOPER TOOLS -> TOOLS -> DATABASE ADMIN to open adminer and export just the tables you're interested in, then import them into your development site.

otherwise paul should be back around later on in the day.

@Michael - thanks for the tip. I used that helpful capability several times in the past to build our alpha environment (in particular, getting SB template overrides over from production).


--
TiG

As, to our knowledge, you are the only site using the Discussion module, we actually fixed up your database table 'by hand' as that was a lot quicker and easier than writing repair code for the module (although the module code has been updated to work with the new table schema). Here is what we did -

1) Make a temporary jr_jrdiscussion_follow_topic_tmp table -
CREATE TABLE `jr_jrdiscussion_follow_topic_tmp` (
`follow_topic_id` int(11) unsigned NOT NULL DEFAULT '0',
`follow_user_id` int(11) unsigned NOT NULL DEFAULT '0',
`follow_created` int(11) unsigned NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

2) Copy only the unique values from the existing table to the temporary one -
INSERT INTO jr_jrdiscussion_follow_topic_tmp
SELECT follow_topic_id, follow_user_id, follow_created FROM jr_jrdiscussion_follow_topic GROUP BY follow_topic_id, follow_user_id

3) Make the follow_topic_id and follow_user_id keys as unique

4) Drop the original jr_jrdiscussion_follow_topic table

5) Rename the jr_jrdiscussion_follow_topic_tmp to jr_jrdiscussion_follow_topic


--
Paul Asher - JR Developer and System Import Specialist

@Paul Thanks for the instructions

Nobody else uses discussion? Brian hinted at that but I did not think NT was that unique.

NT is planning on a major version upgrade. This will enable us to rebuild the site from scratch using a fresh (current) jamroom platform with all the advantages that obviously brings. (Of course existing data will constrain us a bit.) When we do that, we might have the opportunity to migrate away from jrDiscussion. We want (need) to retain the concept of a public artifact (let's call it an article but logically it is a discussion or a blog) that presents content and hosts a stream of comments. What module(s) would you folks prefer we use? Very good information for us to have going forward.


--
TiG

Hi Tig
I cannot say for sure that no one else uses the Discussion module, but we typically get forum posts and support tickets about every other Jamroom module, but only queries about the Discussion module from you (NT), hence our assumption.
The Discussion module was originally sponsored by NT as upon migration to Jamroom, it was essential for you to have threaded comments/posts to discussion topics, which our Forum module doesn't support. If threaded posts are no longer a necessity, I would strongly suggest the going forward you use the Forum module instead, which provides the same functionality as the Discussion module but is more robust and has greater scalability.
hth


--
Paul Asher - JR Developer and System Import Specialist

@Paul

Sounds like we should investigate retrofitting threading into jrForum via an ntForum module. Will investigate the feasibility of this when we get to that point. Thanks much for the suggestion. That is the answer I expected based on what Brian noted earlier.

Threading will never NOT be a necessity for NT.


--
TiG

I would recommend staying with the Discussion module. Adding threading to the forum is likely to be more challenging then just figuring out a good archive scheme for the Discussion module. The recent performance improvements that came out in Comments 2.0 should allow you to continue using the Discussion module for some time to come, and moving to an archive setup should allow you to use it indefinitely.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

@Brian - thanks for the advice. I wish the truth were the opposite though because it would be much better for NT to be based on the most highly supported, highly used components of the platform. NT necessarily must customize since it is a discussion / debate forum. Under a new design we would naturally prefer to customize from the tree trunk and major branches rather than a relatively isolated minor branch.


--
TiG

threaded (anything) isn't highly used.