Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
When there is a thread with a lot of users in it, this can lead to mysql/mariadb limits on the number of joins.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#2 | 3154558.patch | 4.23 KB | heddn |
Comments
Comment #2
heddnHere, we leverage SQL, PHP and the URL context to get the same result, but with a lot fewer joins.
Comment #3
catchThe approach in #2 looks sensible to avoid hitting the join limit. If there turns out to be a pure-SQL way to achieve the same thing, this at least gives us a scalable basis to work from.
Comment #4
phjou@heddn @catch Is there any of you who wants to be become co-maintainer? Just to have the right to merge patches, you both have a strong experience with Drupal and @catch I've seen you over multiple issues on this module.
We currently are two co-maintainers, I am basically merging the easy issues since I stopped using the module and I am maintaining other projects. And I've not seen any activity from @anmolgoyal74 for a while.
Comment #5
heddn@phjou thank you for your kind offer. I don't have any aspirations of stewarding this module excessively, but if reviewing a few patches here and there and committing things that make sense is OK with you, then please add me as a committer.
Comment #6
phjou@heddn Just to let you know that I gave you access to commit and make releases. So at least you can merge the issues you solved and you encounter on your project. It will be better than nothing.
Comment #7
heddnThe issue with multiple threads with the same users in them is lightly touched upon in #2960360: Add a method to remove a user from a thread. That is partially worked around here in that in the majority of cases (at least in the site I'm using this module), we already have the thread id. This helps protect against thread loading from the wrong thread. But only if you visit /private-messages/{private_message_thread}. The fix here doesn't seem to make any of the problem _worse_. In fact, it might make the situation slightly better. With that in mind, I think this is safe to commit. Any confirmation on that feeling?
Comment #8
catchAgreed, we should be relying on thread ID where it's available. Relying on thread members could probably be limited to creating a new private message and typing in the list of members manually to match to existing threads.
Comment #10
heddnI think the feedback/discussion here is enough to grant a commit here is acceptable. Thanks for everyone's thoughtful feedback.