Missing junction table

[ronlinet]

I went through all available messenger solutions in Laravel and I think that this project is the best pluggable solution out there.
I am reusing your package and while querying the DB I have noticed missing foreign keys and junction table between the messages and threads.
Of course the message querying does the trick without associative entities but the relational bible says otherwise.
I am attaching the junctions table schema as well as the code.
Thank you for your open source contribution.
Regards.

CREATE TABLE IF NOT EXISTS `messages_has_threads` (
  `id` INT(10) NOT NULL,
  `messages_id` INT(10) UNSIGNED NOT NULL,
  `threads_id` INT(10) UNSIGNED NOT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_messages_has_threads_threads1_idx` (`messages_id` ASC, `threads_id` ASC),
  CONSTRAINT `fk_messages_has_threads_messages1`
    FOREIGN KEY (`messages_id` , `threads_id`)
    REFERENCES `messages` (`id` , `id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_messages_has_threads_threads1`
    FOREIGN KEY (`messages_id` , `threads_id`)
    REFERENCES `threads` (`id` , `id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE)

[cmgmyr]

hey @ronlinet, thanks for the discussion thread.

I see a lot of value in the junction table. Since the thread can query all of the messages with the same id and messages know which thread they belong to, the junction table seems unnecessary. Does it have an extra benefit that I'm missing?

We originally had foreign keys on the tables, but it introduced a lot of issues in some applications. Since you can override any of the models in the config, and the models could have different table names, this introduced conflicts. We decided to drop FK handling in the package directly and leave that up to the individual application to add or not.

[ronlinet]

Hi @cmgmyr

Thank you for considering the use case.

After reviewing the things I do agree that a junction may be in this case an overkill.

There is still an advantage of ON DELETE CASCADE option where MySql takes care of associated messages deletion without requiring you guys writing any single line of PHP.

Sure things do work well in both cases :) .

Feel free to close the issue.

Thank you for your time.